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DECUS, U. S. Chapter 
219 Boston Post Road. (BP02) 
Marlboro, MA 01752 


Dear DECUS Member: 

During November 1987, the DECUS US Chapter sent out a survey form to you. the readers of the 
SIGs Newsletters. My first act upon assuming the reins of SIG publications chair, is that of reporting 
the results of this survey to you. 

Of approximately 8000 forms mailed, 1386 were returned by the subscribers. This itself is remarkable, 
since no return envelope was enclosed, and the dead-line was on the order of two or three weeks. 
Although more exhaustive analysis is available from Joel Snyder, (who I herein thank for his detailed 
statistical analysis of the data,) I will try to summarize the results here. 

It appears that the great majority of the respondents have subscribed to the newsletter since its incep¬ 
tion, (86%,) and plan to re-subscribe, (96%.) Most were also satisfied with the current arrangement of 
articles, (90%,) and liked the combined mailing, (the "BIG ONE") better than separate SIG newsletters, 
(94%.) 

As far as price, 70% of you think that 35$ is a realistic price for the news-letters, while 22 % would 
even spend 50$ for it. In retrospect, however, I don’t think we would find many subscribers that would 
take the time to respond to a survey if they thought the newsletters weren’t worth the money. 

Also surprising was the level of reader response back to the SIGs. Fully 26% of you had sent in a 
questionnaire page, and about 10% had actually submitted an article. That last percentage seems very 
high to me. As an editor, it warms the cockles of my heart. 

A large majority, (77%,) preferred technical articles over managerial, or liked both types, (14%.) Only 
8% of the readers wanted more managerial articles, which means that the newsletter doesn’t end up on 
too many V-P’s desks. We’re read by the shirt-sleeves and blue-jeans types more than the pin stripers. 

The newsletter bounces around a lot. 76% of you pass it on to from 1-3 people, 14% hand it down to 
3-6, and only 6% are the only readers. 

All in all we are heartened by this response. We seem to be delivering a pro-duct that you people want. 
The only trouble with this survey is that we seem to have a self-selection process. The 17% or so who 
did respond seem to be "gimmee that old-time computing" DECUS stalwarts who bemoaned the 
passing of front panels and switch registers. DECUS is a society constantly in flux, and the Newsletters 
should change with that flow. It’s hard, however, to chart a course without good data about the cur¬ 
rents, and we seem to only have data about the waters astern of us. If any of you readers feel the 
newsletter isn’t delivering what you want and are willing to spend some time writing a letter telling us 
why, I would greatly appreciate it. (See my address in the IAS SIG information section.) 


In closing, let me state that there are 21 hard-working editors, 21 SIG chairs, and numerous other 
DECUS members committed to improving this product. We’re looking at marketing issues, trying to 
improve the looks, trying to streamline submission methods, and still stay within budget. We’ve come a 


long way from the first issue of the "Big one" but we still have a ways to go. 


>ng way troi 


orger 


(See the reverse side for condensed survey results.) 


SIG Pubs Chair 
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1) How long have you subscribed to the DECUS SIG’s Newsletter? 

[6.9%] less than 1 year [5.8%] 1 year [86.4%] 2 years 

2) Do you plan on resubscribing to the newsletter when your subscription expires? 

[96.5%] yes [2.9%] no 

3) Have you ever used the questionnaire section? 

[26.0%] yes [11.1%] no 

If no, check reason: 

[ 5.8%] too many different questionnaires 
[21.8%] not interested 
[35.0%] other 

4) I prefer [77.4%] technical [8.1%] management articles (both 14.5%) 

5) Have You ever submitted an article? 

[9.6%] yes [90.4%] no 

If no, check reason: 

[50.5%] nothing to say 
[ 2.2%] don’t know how 
[ 2.2%] didn’t know I could 
[ 1.4%] why should I 
[35.8%] other 

6) Are there specific type articles you would like the newsletter to include? 

[39.2%] yes [60.8%] no 

If yes, please identify: (Many asked for more in-depth and how-to articles) 

7) Do you perceive yourself aligned with a SIG? 

[76.1%] yes [23.9%] no 

8) Are you satisfied with the current arrangement of articles? 

[90.2%] yes [9.6%] no (both 0.2%) 

9) Would you prefer [94.3%] combined or [5.5%] separate mailings per month? 

10) The value of the current newsletter is: 

[70.0%] $35.00 
[21.8%] $50.00 
[ 3.4%] $75.00 
[ 3.0%] $100.00 

11) How many co-workers read your copy of the newsletter? 

[75.9%] 1-3 [13.6%] 3-6 [3.7%] 6-10 [0.7%] more than 10 

12) What do you consider the best feature of the newsletter? 

246 responded with "All of it together" 

117 responded with "Pageswapper - correspondence" 

116 responded with "Good Technical information" 

13) What do you consider the worst feature of the newsletter? 

99 responded with "Some SIGs appear inactive - drop or realign" 

90 objected to the landscape mode 

14) Do you have any additional suggestions? 

25 suggested a yearly index of articles 
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Contributions 


Contributions for the newsletter can be sent to either of the following addresses: 


Editor, DATATRIEVE Newsletter 
c/o DECUS U.S. Chapter 
Company 219 Boston Post Road, BP02 
Marlboro, MA 01752 


Joe H. Gallagher, Ph. D. 
4GL Solutions 
10308 Metcalf, Suite 109 
Overland Park, KS 66212 


Letters and articles for publication are requested from members of the SIG. They may 
include helpful hints, inquiries to other users, reports on SIG business, summaries 
of SPRs submitted to Digital or other information for members of the DATATRIEVE SIG. 
Machine readable input is highly desirable and machine-to-machine transfer of mater¬ 
ial is preferred, but most anything legible will be considered. However, this news¬ 
letter is not a forum for job and/or head hunting, nor is commercialism appropriate. 
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Chairman's Corner 

Joe H. Gallagher, Ph. D., 4GL Solutions, Overland Park, KS 66212 


It seems like only yesterday that I took over as Chair of the DATATRIEVE/4GL SIG at 
the Dallas Symposium in the Spring of 1986. Time really does go quickly when you are 
having fun! However, if I do the same thing for very long, I get lazy and compla¬ 
cent. So when it was time to decide if I would seek another two year term as Chair, 
it was an easy decision for several reasons - an excellent (and probably superior) 
replacement was available and I was eager to return to my first love of editing the 
newsletter. 

The activities of the SIG have changed significantly during the last two years. Two 
and one-half years ago DATATRIEVE in its various versions was our only interest? we 
were a one-product SIG. Now, at least at Symposia, more than half of our activities 
are centered around DEC and non-DEC fourth generation languages. Computers change? 
computer languages change? we change? and the organizations we participate in change. 

This is really not good-bye? I am only changing hats. Please give Don Stern, the new 
SIG Chair, all your support and best wishes. And I will now look forward to receiv¬ 
ing your submissions to the newsletter. 

We look forward to seeing you in Cincinnati at the Spring Symposium. As always, we 
will make new friends and learn new things. 


Letters to Editor 

Dear Editor, 

In my recent article, ’’DATATRIEVE DATES and Leap Years" (DECUS U. S. Chapter SIGs 
Newsletters, February 1988, Volume 3, Number 6, DTR-15 - DTR-16), there is an error 
in the comparison of lengths of tropical years and mean modified Gregorian years. 
The stated values are correct, but since the mean modified Gregorian year is slightly 
longer than the tropical year, the modified Gregorian calendar will slowly fall be ¬ 
hind (rather than gain on) the tropical year. Hence, about every 3320 years, an 
additional day (in addition to leap day) would have to be inserted to bring the modi¬ 
fied Gregorian calendar back into approximate agreement with the earth's position in 
its orbit. 

I apologize for the error. 


Sincerely 

James J. Fullerton (signed) 
Institute of Logopedics 
Wichita, Kansas 


Dear Editor, 

I read with interest James Fullerton's letter in the February 1988 Wombat Examiner 
and 4GL Dispatch concerning the method of determining leap years. I don't have any 
astronomy texts here myself, being a Chemical Engineer, but it did bring to mind the 
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way the folks out here in Arizona sometime back used to do their timing/dating. The 
HOHOKAM people used an algorithm similar to the following: 

DEFINE PROCEDURE CBS 
DECLARE AZMUTH PIC 999. 

DECLARE ELEVATION PIC 999. 

FOR MUD_H0USE WITH WALL_THICKNESS_IN_FEET GE 2 

! construct an enclosure, multipurpose, 

! including living quarters. 

B0RE_H0LE USING BEGIN 

AZMUTH = DETERMINE ! watch the sun and see where shadows 

ELEVATION = DETERMINE ! fall at beginning of planting season, 

! year after year after year. 

END 

FIND STAKE ! a Saguaro rib might work well 

READY STAKE 

FOR STAKE ALIGNED WITH HOLE USING ROCK BEGIN 
DRIVE STAKE 
END 

READY GROUND SHARED ! lots of mouths to feed 

WHILE SUNLIGHT__THROUGH_HOLE = STAKE BEGIN 
PLANT CORN 
PLANT BEANS 
PLANT SQUASH 
END 

END PROCEDURE 


Leonard E. Herzmark, P. E. (signed) 
Maricopa County Health Department 
Phoenix, Arizona 


WOMBAT WIZARD 

Dear Wombat Wizard: 

I have run into a very peculiar problem with VAX-DATATRIEVE V4.1, which I'm certain 
did not exist in earlier versions. I have two domains, DELIVERIES and HEADERS, each 
of which has two keyed fields? both of which are USAGE LONG. I need to match up 
these two domains on both fields: SA_SOM (the primary key which is "Seconds at Start 
of Message") and UMID (the secondary key which is "Unique Message ID"). No matter how 
I phrase the statements, DATATRIEVE uses only the primary key and ignores the second¬ 
ary key. This results in a very slow retrieval. Procedures which used to take less 
than 1/2 hour now fail to complete after more than 15 hours. No matter how I phrase 
the query or add parenthesis, I can't get DATATRIEVE to use both keys to match the 
two domains. 

The applicable part of the record definition for the domain HEADERS is: 

DEFINE RECORD HEADER_REC USING 
01 HEAD. 

03 SYSTEM_ID PIC X(5). 

03 SA_S0M USAGE IS LONG. ! <Number, primary key> 

03 UMID USAGE IS LONG. ! <Number, alternate key> 

03 DATE USAGE IS DATE. 

03 TIME COMPUTED BY FN$TIME(DATE). 

. . . ! OTHER FIELDS 
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The applicable part of the record definition for the domain DELIVERIES is: 


DEFINE RECORD DELIVERY_REC USING 
01 DELIV. 

03 SYSTEMID PIC X(5). 

03 SA_S0M USAGE IS LONG. ! <Number, primary key> 

03 UMID USAGE IS LONG. ! <Number, alternate key> 

03 DATE USAGE IS DATE. 

03 TIME COMPUTED BY FN$TIME(DATE). 

. . . ! OTHER FIELDS 


When I execute the statements in DATATRIEVE: 

FOR HEADERS WITH SA_S0M GT 0 BEGIN 
PRINT SA_S0M, UMID, TIME 

FOR DELIVERIES WITH DELIV.UMID = HEAD.UMID AND 
DELIV.SASOM = HEAD.SA_SOM BEGIN 
PRINT SA_S0M, UMID, TIME 
END 
END 


with the /DEBUG qualifier and the output is directed to a logfile with an OPEN state¬ 
ment, the relevant part of the log file reveals: 

Performing GTR boolean on RMS key field HEADERS.SA_S0M 
Performing EQL boolean on RMS key field DELIVERIES.SA_S0M 

Seconds at Unique 

Start of Message 

Message ID TIME 

17,778 12,763,793 15:02:34 

17,781 2,631,798 00:00:05 


Seconds at Unique 

Start of Message 

Message ID TIME 

17,781 2,631,798 00:05:24 

17,781 2,631,843 00:02:55 


Am I specifying the query incorrectly? I'm certain I've set up expressions like this 
before, and I'm equally certain that this specific definitions used to retrieve data 
much faster than it does now. The only thing I can think of which changed recently 
is that I moved the data files off of my default login disk and onto a secondary 
disk. 


Signed, 

Chasing Two Keys 
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Dear Two Keys, 


Your attacked your problem very well with 
SRUN/DEBUG SVS$SYSTEM:DTR32 
and the use of a logfile with the statement 
DTR> OPEN LOGFILE.LOG 

However, it takes a key ring to manage two keys, but in DATATRIEVE there are some 
definite rules for the evaluations of compound Booleans. DATATRIEVE sets up a prior¬ 
ity to evaluate compound Boolean expressions that include key fields. For any do¬ 
main, the (one and only) key that is chosen depends on three factors: 


1. Exact or range retrieval 

Exact retrievals use EQUALS or STARTING WITH, 
Range retrievals us GT, GE, LE, LT, or BT 

2. Key is NO DUP or DUP 

3. Primary or alternate key 


DATATRIEVE*s priority in choosing a key is: 


Order Type 

of Retrieval 

DUP/NO DUP 

1 

Exact 

NO DUP 

2 

Exact 

NO DUP 

3 

Exact 

DUP 

4 

Exact 

DUP 

5 

Range 

NO DUP 

6 

Range 

NO DUP 

7 

Range 

DUP 

8 

Range 

DUP 

Thus, even if 

you specify a 

retrieval on 


only one according to its priority. 


Type of Key 

Primary 

Alternate 

Primary 

Alternate 

Primary 

Alternate 

Primary 

Alternate 

two or more keys, DATATREIVE will choose 


Since you have moved your file to a secondary disk, the Wizard's crystal ball says 
that your file is now much larger now than it was originally. It is thus likely that 
when the file access had acceptable performance, the number of duplicate records with 
the same primary key was small. Now that your file has grown larger, there are pro¬ 
bably many (perhaps hundreds or thousands) of duplicates for each primary key? se¬ 
quentially searching these duplicates leads to very poor retrieval performance. 


One way to beat this performance hit is to give up a little disk space by changing 
the data types of the two fields, SA_SOM and UMID, to strings and use a composite 
key. Consider record definitions like 


DEFINE RECORD HEADER_REC USING 
01 HEAD. 

03 SYSTEMJD PIC X(5). 

03 NEW-KEY. ! primary key 
05 SA_S0M PIC 9(8). 

05 UMID PIC 9(8). 


DEFINE RECORD DELIVERY_REC USING 
01 DELIV. 

03 SYSTEMJD PIC X(5). 

03 NEW-KEY. ! primary key 

05 SA_S0M PIC 9(8). 

05 UMID PIC 9(8). 
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03 DATE USAGE IS DATE. 
03 TIME COMPUTED BY 
FN$TIME(DATE). 

! OTHER FIELDS 


03 DATE USAGE IS DATE 
03 TIME COMPUTED BY 
FN$TIME(DATE). 

! OTHER FIELDS 


The records are now eight bytes larger than before, but the new 
primary key, NEW-KEY, will give very much better performance when 
the records are joined. 


The Wizard 


Tracking User Logins 

Bart Z. Lederman, WU World Communications, Inc., New York, NY 10004-2464 


There are various reasons why someone would want to keep track of who logged into a 
system, when, for how long. One is for security purposes to see when people are 
logging in, if an account is being used excessively, and so on. Another is to track 
users to see if they are logging in when they are supposed to. As part of the opera¬ 
tion of the DECUServe system, moderators are supposed to log in regularly and check 
their conferences, and DECUServe management wanted a method for checking this. What 
follows are some of the procedures I put together for them, and which, in most cases, 
I'm running on my own system as well. 

Unused Accounts 

One thing I had to check for on my system was to see if there were accounts which 
were no longer being used. For example, on my system some accounts were created for 
test purposes, but we don't always get notified when use of the account stops. This 
may be obtained from a listing created by AUTHORIZE from the information in the 
SYSUAF.DAT file, the format does not lend itself to easy scanning to find accounts 
which have not been used for some time. I created a simple report that lets me know 
when each users' last login date was by directly reading the SYSUAF.DAT file.^ 

REDEFINE PROCEDURE REP0RT_LAST_L0GIN 

f 

! Quick report of who logged in when. 

i 

READY SYSUAF 

REPORT SYSUAF WITH USERNAME NOT C0NT "SYSTEM","PASSWORD" SORTED BY ACCOUNT, 

USERNAME ON *."Filename or TT" 

SET REP0RT_NAME = "Date of Last Login" 

PRINT ACCOUNT, USERNAME USING T(20), DATE_LAST_INTERACTIVE_LOGIN, 

DIRECTORY USING T(24) 

AT BOTTOM OF ACCOUNT PRINT SKIP 1 
END_REP0RT 

END PROCEDURE 
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Date of Last Login 

l-Feb-1988 
Page 1 

ACCOUNT 

USERNAME 

DATE 

LAST 

INTERACTIVE 

LOGIN 

DIRECTORY 


DDSNET 

SNACSV 


[MBS.DOS.SCR] 

[SNACSV] 

ALLIN1 

ALLIN1 

l-Feb-1988 

[ALLIN1] 

ASD 

ASD 

JONES 

LEDERMAN 

l-Feb-1988 

l-Feb-1988 

[JONES] 

[LEDERMAN] 

DECNET 

DECNET 


[DECNET] 

FIELD 

FIELD 

4-Nov-1987 

[SYSMAINT] 

MBWATCH 

MBWATCH 


[MBS.MB.MBSSCRATCH] 

MROUTER 

MROUTER 

MBMANAGER 

MRMANAGER 

25-Jan-1988 

25-Jan-1988 

[MBS.TOOLS] 

[MBS.MR.WRK] 


This could just as easily be sorted by DATE_LAST__INTERACTIVE_LOGIN to put the oldest 
accounts first, but for my purposes it was easier to read sorted by user name. 

Note that since this procedure requires read access to SYSUAF.DAT, which is normally 
protected against access by anyone except the system manager and similar privileged 
accounts, the procedure must be run by someone who is privileged, or submitted as a 
batch job under a privileged account. Also note that all of these reports were ac¬ 
tually generated on my system with the procedures shown, but I have edited the output 
to disguise some of the user names. If they are not in alphabetical order, it's not 
a bug in DATATRIEVE. 


Who Logged in Recently? 

One report desired by DECUServe management is a list of who logged in in the past 72 
hours. This may also be obtained from SYSUAF.DAT, and in this case is certainly 
obtained more easily with DATATRIEVE. 

REDEFINE PROCEDURE L0GIN72 

j 

! Report users who have logged in in the past 72 hours. 

I 

DECLARE SELECT_DATE USAGE DATE. 

DECLARE SELECT_QUAD USAGE QUAD. 

I 

SELECT_DATE = "NOW" 

j 

! Convert date to clunks, subtract 72 hours in clunks, 

! convert back to date. 

\ 
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f 


SELECT_QUAD = SELECT_DATE 

SELECT_QUAD = SELECT_QUAD - 72 * 60 * 60 * 10000000 
SELECT_DATE = SELECT_QUAD 

j 

READY SYSUAF SHARED READ 

i 

! Read the SYSUAF.DAT file (requires the user to have the proper privileges). 

i 

REPORT SYSUAF WITH DATE_LAST_INTERACTIVE_L0GIN GE 

SELECTDATE SORTED BY ACCOUNT, USERNAME ON *."Filename or TT" 

SET REPORTNAME = "Logins in the past 72 hours" 

PRINT ACCOUNT, USERNAME USING T(20), DATE_LAST_INTERACTIVE_LOGIN, 
FN$TIME(DATE_LAST_INTERACTIVE_LOGIN)("TIME"/"LAST"/"LOGIN") USING X(11) 
AT BOTTOM OF ACCOUNT PRINT SKIP 1 
END_REPORT 
END PROCEDURE 


Logins in the past 72 hours l-Feb-1988 
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DATE 




LAST 

TIME 



INTERACTIVE 

LAST 

ACCOUNT 

USERNAME 

LOGIN 

LOGIN 

ALLIN1 

ALLIN1 

l-Feb-1988 

08:13:31.30 

ASD 

BROWN 

l-Feb-1988 

12:22:22.21 

ASD 

WILLIAMS 

l-Feb-1988 

10:37:58.85 

SYSMGR 

SYS LEDERMAN 

l-Feb-1988 

15:45:20.34 


Failed Logins 

Something which can be very important to know is how many attempts to log into a 
system failed. This is often an important indication that someone is attempting to 
break into a system. It can also signal a bad communication line ("garbage" is caus¬ 
ing the users' attempts to log in to fail), or a bad installation (Message Router was 
installed with the wrong password so all of the network logins fail), or just that a 
user is having difficulties. This information can be recorded by VMS System Account¬ 
ing, supplied with the VAX/VMS operating system. System accounting is normally star¬ 
ted when you boot your system with commands in SYS$MANAGER:SYSTARTUP.COM similar to 
the following: 

$ SET ACCOUNTING/ENABLE=(BATCH, DETACHED, INTER, LOGIN_FAIL, 

MESSAGE, NET, PR0C, SUBPR0C) 

You can select which types of events are logged? I normally activate everything EX¬ 
CEPT image accounting. Specifically, I activate all types of login activity, and 
login failures. 

The information normally goes into SYS§ MANAGER: ACCOUNTNG. DAT, but I find it much 
easier if I have one file per day. Therefore, I have a batch job that runs every 
night at midnight which (among various other duties) creates a new file like this: 
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$ yday = F$CVTIME( “YESTERDAY", “ABSOLUTE", “DAY") 

$ ymon = F$CVTIME( “YESTERDAY", “ABSOLUTE”, “MONTH") 

$! 

$! The System Accounting file is reset. 

$! 

$ WRITE SYS$OUTPUT “Set new System accounting file” 

$! 

$ SET ACCOUNTING/NEW_FILE 
$ file = F$SEARCH(“ACC0UNTNG.DAT;-1“) 

$ IF file .EQS. ““ THEN file = F$SEARCH(“ACC0UNTING.DAT;-1“) 

$ IF file .EQS. ““ THEN GOTO errlog 
$ RENAME 'file' accounting.'yday''ymon' 

This automatically gives me one accounting file per day. Unfortunately, the result- 
ing file is almost impossible to read directly with DATATRIEVE (or most other VAX 
languages) because of it's format. I therefore wrote a program which converts the 
System Accounting file into a file with normalized records and fixed length fields 
which can easily be read by DATATRIEVE (or anything else).^ 

Once the System Accounting file is in an easily processed format, it is simple to 
report login failures: 

REDEFINE PROCEDURE L0GFAIL_REP0RT 
! 

! This reports on login failures in an accounting file. 

i 

READY ACC 

REPORT ACC WITH PACKET = “Logfail" ON ♦."File or TT“ 

SET REPORTJIAME = “Login Failures" 

SET NO DATE 

AT TOP OF PAGE PRINT REPORT_HEADER, SYSTEM_DATE(-), SKIP, COLUMN_HEADER 
PRINT SYSTEM_TIME, USERNAME, ACCOUNT, NODE, TERMINAL, REMOTE_ID 
END_REPORT 
END_PROCEDURE 

Login Failures Page 1 

25-Jan-1988 


SYSTEM 





REMOTE 

TIME 

USERNAME 

ACCOUNT 

NODE 

TERMINAL 

ID 

10:29:24.26 

LEDERMAN 

<net> 

SYS30 


SYS_LEDERMAN 

10:36:01.12 

WILLIAMS 

<login> 


VTA67: 


11:35:01.59 

<login> 

<login> 


LTA175 


12:37:02.60 

MRGATE 

<login> 

SYS31 

RTA1: 

LEDERMAN 

16:32:56.72 

BROWN 

<login> 


VTA69: 


19:20:04.25 

<login> 

<login> 

SYS31 

RTA1: 

SMITH 


I now have my nightly batch job print out this report on a regular basis, so it's 
ready when I come in in the morning. 
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Reporting User Logins 


Another report requested by the DECUServe management, and one which may be of inter-* 
est to others, is a report of when users logged in, and how much time they spent on 
the system. This is easily obtained from the System Accounting file once it has been 
converted. 

REDEFINE PROCEDURE REPORTJJSER_$ESSION_DETAILS 

l 

! Report the number of user interactive sessions, and the amount 
! of time spent (in detail). 

j 

READY ACC 

REPORT ACC WITH PACKET = "Interactive" SORTED BY ACCOUNT, 

USERNAME ON *."File or TT" 

PRINT ACCOUNT, USERNAME, ELAPSED_MINUTES 
AT BOTTOM OF USERNAME PRINT SKIP, "Totals", 

TOTAL(ELAPSED_MINUTES) USING ZZZ,ZZ9, 

COUNT ("Number"/"of"/"Sessions"), SKIP 
AT BOTTOM OF ACCOUNT PRINT SKIP 
END_REPORT 
END_PROCEDURE 

A portion of this report looks like: 

l-Feb-1988 
Page 1 

Number 

ELAPSED of 


ACCOUNT 

USERNAME 

MINUTES 

Sessions 

ASD 

BROWN 

405.73 


ASD 

BROWN 

95.78 


Totals 


502 

2 

ASD 

JONES 

40.55 


ASD 

JONES 

95.53 


ASD 

JONES 

110.14 


ASD 

JONES 

13.78 


Totals 


260 

4 

ASD 

SMITH 

228.94 


Totals 


229 

1 

ASD 

WILLIAMS 

183.92 


ASD 

WILLIAMS 

24.77 


Totals 


209 

2 


I also have a similar report which only gives the summary, without the individual 
logins. For my purposes, I organize users by account, then by name. The account 
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corresponds to the account field in SYSUAF.DAT, but it is filled in by System Ac¬ 
counting so that a user who runs this report does NOT have to have access to SYSUAF, 

and therefore does not have to be privileged. 

Although this report includes only interactive sessions, it is also possible to ob¬ 
tain reports for network and batch sessions, and for subprocesses, if they were en¬ 
abled when System Accounting is started. 

A Login History 

In addition to knowing which people logged in recently, there may also be reasons to 
know how people logged in over a period of time. While it would be possible to sim¬ 
ply examine the System Accounting files for that number of days, or let System Ac¬ 
counting run continuously for the desired time frame, there are drawbacks to both of 

these approaches. First, the System Accounting file can get quite large. I have 
Message Router on my system which runs a lot of batch jobs and network logins, my 
System Accounting file runs up to 500 blocks a day, and sometimes more. A month's 
worth of data can easily run 14,000 blocks, and would take a long time to process in 
one file or even longer as 28 to 31 separate files. Therefore, I decided to create a 
separate domain just to store user's login histories and update it nightly. What I 
am storing is how many times a user logged in on each particular day (I could also 
store elapsed time, or each individual login, but based on what I interpreted as was 
needed for DECUServe, just the number of logins was needed). 

DEFINE RECORD L0GIN_HIST0RY_REC0RD OPTIMIZE 

! 

! This record tracks the login history of a user. There should be 
! one record for each user/account per day logged in. 

! 

01 LOGIN_H ISTORY_RE C. 

10 USERNAME PIC X(16) 

QUERY_HEADER "User Name". 

10 ACCOUNT PIC X(8) 

QUERY_HEADER "Account". 

10 L0GINDATE USAGE DATE. 

10 LOGINS PIC 99 
EDIT_STRING Z9 

QUERY_HEADER "Times7"Logged7"In". 

* 

This is updated nightly from the converted System Accounting file: 

DEFINE PROCEDURE L0GIN_HIST0RY_FR0M_ACC 

j 

! Create a history of number of times each user logged in on 
! each date by reading the processed System Accounting Files 

j 

READY ACC 

READY LOGIN_HISTORY WRITE 

j 

DECLARE N PIC 99. 

DECLARE DATE_0NLY USAGE DATE. 

DECLARE DATE_STRING PIC X(ll). 

i 

! Count interactive sessions only (could later separate logfails 
! with the same pass if desired). 
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I 

FOR ACC WITH PACKET = "Interactive M BEGIN 

i 

! Must extract date only portion (no time) 

i 

DATE_STRING = 

FN$UPCASE(FORMAT(ACC_REC.SYSTEM_DATE) USING DD_MMM_YYYY) 
DATE_0NLY = FN$DATE(DATE_STRING | " 00:00:00.00") 

! Check to see if this person has a history record. 

! If so, update it. 

N = 0 

FOR L0GIN_HIST0RY WITH 

LOGIN_HISTORY.USERNAME = ACC_REC.USERNAME AND 
LOGIN_HISTORY.LOGIN__DATE = DATE_0NLY BEGIN 

! This person logged in before, so the record can be updated. 

MODIFY USING LOGINS = LOGINS + 1 
N = N + 1 


IF N = 0 THEN BEGIN 

i 

! No login history record for this person, create one 

j 

STORE L0GIN_HIST0RY USING BEGIN 
USERNAME = ACC_REC.USERNAME 
ACCOUNT = ACC_REC.ACCOUNT 
L0GIN_D ATE = DATE_0NLY 
LOGINS = 1 
END 
END 

? 

! This shouldn't happen. 

! 

IF N > 1 THEN BEGIN 

PRINT "Error with login history, N = ", N, USERNAME, ACCOUNT 
END 

I 

END 

END_PROCEDURE 

Note that this procedure is "self updating". When a new user is added, the procedure 
will automatically start recording information for that user, but will not create any 
new records for people who don't log in. 

Once this history file is created, there are various ways the information can be 
used. Again, one of the reports desired for DECUServe was a history of how users 
logged in over the past 28 days. 

This report looks like: 
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DEFINE PROCEDURE L0GIN28 


! Report on login performance for the previous 28 days. 

i 

DECLARE SELECT_DATE USAGE DATE. 

SELECT_DATE = "TODAY" 

SELECT_DATE = SELECT_DATE + (-28) ! Go back 28 days from today 

t 

READY L0GIN_HI$T0RY 

REPORT L0GIN_HIST0RY WITH LOGIN_DATE GE SELECT_DATE SORTED BY 
ACCOUNT, USERNAME ON ♦.“File or TT" 

SET REPORT_NAME = "Login Performance"/"for the previous 28 days" 

AT TOP OF ACCOUNT PRINT COL 5, ACCOUNT 

AT BOTTOM OF USERNAME PRINT COL 15, USERNAME, SPACE 1, 

COUNT ("Number"/"of Days"/"Logged In"), SPACE 1, 

MIN(LOGINS) USING Z9, SPACE 1, 

AVERAGE(LOGINS) USING ZZ9, SPACE 1, 

MAX(LOGINS) USING ZZ9 

END_REPORT 

END_PROCEDURE 

A portion of this report looks like this: 

Login Performance l-Feb-1988 

for the previous 28 days Page 1 


Account 

User Name 

Number 
of Days 
Logged In 

MIN 

Times 

Logged 

In 

AVERAGE 

Times 

Logged 

In 

MAX 

Times 

Logged 

In 

ALLIN1 


ALLIN1 

9 

1 

2 

3 

ASD 


BROWN 

16 

1 

2 

4 


JONES 

15 

1 

2 

6 


LEDERMAN 

22 

1 

4 

10 


SMITH 

19 

1 

2 

10 


WILLIAMS 

20 

1 

3 

10 

MROUTER 


MBMANAGER 

3 

1 

2 

2 


MRMANAGER 

3 

1 

1 

2 

SYSMGR 


SYSTEM 

6 

1 

2 

2 


SYS LEDERMAN 

20 

1 

4 

19 


The purpose of this report for DECUServe is to find moderators who don't log in; 
others might be looking for employees who don't log in. I would be more interested 
in finding excessive logins (a possible security breach). 

Some "GRAPHS" of Login History 

It is often much easier to appreciate data in a graphical form than in columns of 
numbers. I therefore derived a type of graph which shows how people logged in over a 
given month. This requires two record definitions working on the same file, but both 
the domains LOGIN HISTORY BAR and LOGIN HISTORY STRING use the same data file. 3 


DTR-13 




DEFINE RECORD LOGIN_HISTORY_BAR_RECORD OPTIMIZE 

i 

! This is used to create a "graph" of the login history 
! of any number of users. 

i 

01 L0GIN_HIST0RY_BAR_REC. 

10 USERNAME PIC X(16). 

10 ACCOUNT PIC X(8). 

10 MONTH PIC 99. 

10 YEAR PIC 9999. 

10 BAR PIC X(62) 

QUERY_HEADER " ". 


REDEFINE RECORD LOGIN_HISTORY_STRING_REC0RD OPTIMIZE 

f 

! This gives an alternate access to the login history graph record 
! so that the individual days can be filled in. 

f 

01 LOGIN_HISTORY_STRING_REC. 

10 USERNAME PIC X(16). 

10 ACCOUNT PIC X(8). 

10 MONTH PIC 99. 

10 YEAR PIC 9999. 

10 STRING OCCURS 31 TIMES. 

20 CHAR PIC XX. 

20 NUMBERS REDEFINES CHAR. 

30 FILLER PIC X. 

30 NUM PIC 9. 


DEFINE DOMAIN LOGIN_HIST0RY_BAR USING LOGIN_HISTORY_BAR_RECORD ON 
LOGIN_H ISTORY_BAR.SEQ; 

DEFINE DOMAIN LOGIN_HISTORY_BAR USING LOGIN_HISTORY_STRING_RECORD ON 
LOGI N_HISTOR Y_BAR.SEQ; 


With these two definitions/ it is possible 
graphed this with one and two columns per 
read so I will show it here. Except for 
cesses are identical. 

DEFINE PROCEDURE MAKE_LOGIN_HISTORY_GRAPH 

f 

! Plot login history for a month. 

j 

READY LOGIN_HISTORY 

DECLARE BLANK PIC X(62). 

DECLARE INC PIC 999. 

DECLARE TMP PIC 999. 

DECLARE TDAY PIC 99. 

DECLARE TMONTH PIC 99. 

DECLARE TYEAR PIC 9999. 

| 


to process the login history file. I have 
day; the two column is a little easier to 
the size of the display fields, the pro- 
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! Fill in the plot pattern. 

t 

BLANK = ■ + I + I + 

INC = 1 


! Prompt the user for the desired month and year 

TMONTH = *."Month (numeric)" 

TYEAR = *. M Year (4 digits)" 

i 

! The following is a fast way to make a new empty file, if you 
! remember to purge old files. 

j 

DEFINE FILE FOR LOGIN_HIST0RY_BAR KEY=USERNAME(DUP), KEY=ACCOUNT(DUP); 

READY LOGIN_HISTORY_BAR WRITE 
READY LOGIN_HISTORY_STRING MODIFY 

FOR LOGIN_HISTORY WITH FN$MONTH(LOGIN_DATE) = TMONTH AND 
FN$YEAR(LOGIN_DATE) = TYEAR BEGIN 

! 

! Find out if there is a plot record for this person/account already. 

TMP = 0 

FOR LOGIN_HISTORY_BAR WITH USERNAME = LOGIN_HISTORY_REC.USERNAME AND 
ACCOUNT = LOGIN_HISTORY_REC.ACCOUNT BEGIN 
TMP = TMP + 1 
END 

i 

IF TMP = 0 STORE LOGIN_HISTORY_BAR USING BEGIN ! no record, 

USERNAME = USERNAME ! must create one 

ACCOUNT = ACCOUNT 
MONTH = TMONTH 
YEAR = TYEAR 

BAR = BLANK ! Put in a "blank" line. 

END 

TDAY = F N $ DAY(LOGI N_DAT E) 

j 

! Retrieve the corresponding user/account record 




FOR LOGIN_HISTORY_STRING WITH 

USERNAME = LOGIN_HISTORY_REC.USERNAME AND 
ACCOUNT = LOGIN_HIST0RY_RE C.ACCOUNT 

BEGIN 

TMP = INC ! start at beginning of line 


! Now move along the string and mark of the current day 

t 

FOR STRING MODIFY USING BEGIN 

IF TMP = TDAY CHOICE OF ! if correct day 

LOGINS GT 9 THEN CHAR = ! too many logins 

LOGINS BETWEEN 1, 9 THEN NUM = LOGINS 

END_CHOICE 

TMP = TMP + INC ! increment to next day 

END 
END 
END 

FINISH LOGIN_HISTORY_BAR 
FINISH LOGIN_HISTORY_STRING 
END PROCEDURE 
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Once this processing is done, actually printing the graph is fairly simple. 
DEFINE PROCEDURE LOGIN_HI$TORY_GRAPH 

t 

! This procedure reads a login history and creates a graph 
! of the days each user logged in. 

j 

READY LOGIN_HIST0RY_BAR 

REPORT LOGIN_HIST0RY_BAR SORTED BY ACCOUNT, USERNAME ON *. M File or TT" 

SET COLUMNS_PAGE = 80 

SET REP0RT_NAME = "Login History" 

SET NO DATE 

j 

AT TOP OF PAGE PRINT REP0RT_HEADER, 

COL 5, MONTH VIA M0NTH_NAMES(-), SPACE 1, YEAR (-), SKIP, 

COL 17, " 1122 3", SKIP, 

COL 17, " 5 0 5 0 5 0“ 

j 

AT TOP OF ACCOUNT PRINT COL 9, ACCOUNT(-), 

COL 17, " + I + I + I" 

j 

PRINT COL 1, USERNAME, COL 17, BAR 

j 

AT BOTTOM OF PAGE PRINT 

COL 17, " 1122 3", SKIP, 

COL 17, " 5 0 5 0 5 0" 

END REPORT 
END_PROCEDURE 

A typical report looks like the following: 
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Footnotes 

The record definition for SYSUAF was published in “Accessing SYSUAF.DAT 
and QUOTA.SYS with DATATRIEVE" by Donald E. Stern, Jr. in the DECUS U. S. 
Chapter SIGs Newsletters, Volume 1, Number 2, pages DTR-12 - DTR-12, 
October 1985 with an Errata in Volume 1, Number 4, page DTR-18. The 
record defintion is also included in the DTR/4GL SIG Tape Collection. 

The program is too long to include here. It has been placed in the 
DTR/4GL SIG Tape collection, which has been on several past VAX SIG Tapes, 
and is in the DECUS library as V-SP-59. Older releases only convert 
process deletion records; the newest version, which will be submitted to 
the Spring 1988 tape copy in Cincinnati, will include conversion of login 
failures and image accounting, and will also include the procedures shown 
in this article, the daily batch job command file, the accounting file 
record definition, etc. 

This technique was published in the Newsletter (Volume 7, Number 1, pages 
DTR-4 - DTR-9, September 1985, “Horizontal Bargraphs Without Graphics 
Devices". The material is also is in the DTR/4GL SIG Tape collection. 
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FROM THE EDITOR... 


In this month’s issue we have two great technical articles, one sheds a new light on the "Janitor" facility 
used to keep wastebaskets emptied on a regular basis. The other article discusses ways of keeping your 
modified scripts, forms, etc. separated from the standard or ’vanilla’ parts of ALL-IN-1. It is a follow up to 
the article Roger submitted last month called "Three Helps for ALL-IN-1 Testing". 

Also in this issue (Fanfare please) we have the updated OA SIG TAPE listing. The new listing contains 
items submitted at and since the Nashville Symposium April 1987 - February 29, 1988). Keep in mind that 
the tape is now available through your Local User Groups. 

I have been very pleased with the quality and quantity of technical articles we have received for publication. 
I encourage you all to keep up the good work! Remember, you can submit articles at any time: technical or 
general in nature. I will let you know when it is received and in which issue the article will appear. 

As usual I will be attending the Cincinnati Symposium this month. I encourage those of you who are 
attending to take a moment or two and give me some feedback on the newsletter. I am always interested 
in your comments, criticisms, suggestions and ideas. 

Regards, 

Therese LeBlanc 
OA Newsletter Editor 
275 London Place 
Wheeling, IL 60090 
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COULD "JANITOR" BE AFFECTING YOUR SYSTEMS’ PERFORMANCE? 

Kae Sobczyk, Cooper Tire & Rubber Co. 


Regularly running the ALL-IN-1 Janitor is supposed to improve performance by cleaning out and reorgan¬ 
izing user and system data files. However, I recently discovered something that indicates the ALL-IN-1 
Janitor may hurt your performance. 

The Tuning chapter of the ALL-IN-1 Manager’s Guide recommends setting global buffer counts for your 
system data files, based on the maximum number of concurrent ALL-IN-1 users you expect on your 
system. During installation or upgrade, the procedure prompts for this max users estimate and sets the 
global buffer counts accordingly. 

However, this global buffer count is not propagated to new versions of the files recreated by SMJANITOR. 
These files are OA$DATA:DAF.DAT, 

OA$DATA:PENDING.DAT, OA$DATA:MEETING.DAT and OA$DATA:ATTENDEE.DAT. The 
SMJANITOR uses FDL files located in OA$LIB to recreate these system data files, The installation/ 
upgrade procedure does not set the global buffer counts in the FDL files when it sets the counts on the 
.DAT files mentioned above. Therefore, when SMJANITOR recreates these files, they default to global 
buffer counts of 0. 

I have submitted an SPR requesting a change to the installation/upgrade procedure. In the meantime, you 
may want to check the global buffer counts on your system data files (with DIR/FULL), and use the SET 
FILE/GLOBALBUFF= 

command to correct the counts. Recommendations for global buffer count values are in Chapter 9 of the 
ALL-IN-1 Manager’s Guide. You will need to shut down ALL-IN-1 to modify these files. Then use the 
EDIT/FDL command to modify the FDL files in OA$LIB that correspond to the system data files. 

OA$DATA:DAF.DAT = > OA$LIB:SDAF.FDL 
OA$DATA:PENDING.DAT = > OA$LIB:PENDING.FDL 
OA$DATA:MEETING.DAT = > OA$LIB:MEETING.FDL 
OA$DATA:ATTENDEE.DAT = > OA$LIB:Attendee.FDL 

If you have any questions about the problem itself or the solution I have suggested, you can call me at (419) 
424-4283. 

Kae Sobczyk 

Cooper Tire & Rubber Co. 

Findlay, Ohio 
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YOURS, MINE, & OURS 

Isolating New and Modified Forms, 

Scripts, & Command Procedures 
from the ALL-IN-1 Originals 

Roger Ellis Bruner, Baptist Foreign Mission Board 


INTRODUCTION: 

Can the new and modified forms, scripts, and command procedures of customized ALL-IN-1 be kept 
isolated from the "plain vanilla" ALL-IN-1 versions and yet be properly accessible? 

And can ALL-IN-1 users be set up to operate at different "levels" of use, each of which requires a different 
combination of form libraries, file search order, and TXL search sequence? 

We believe the answer to both questions is "yes". 

If you read "3 HELPS FOR ALL-IN-1 TESTING" in the February DECUS Newsletter, you know that we 
have been using an OA$DEVLIB:DEVOAFORM forms library for development and testing at the Foreign 
Mission Board. "3 HELPS" describes the need to open and close libraries and to reverse the 
OA$TXL_SEARCH_LAST at will. It also gives some details about the two menu screens, TLIB and 
SETLIB, which perform those functions. You may wish to review "3 HELPS" for some of the details 
which have been purposely omitted from this article. 

Just in the short time since that article was written, we have begun to expand upon the concept of 
separating the new from the old in the hopes of creating a more flexible ALL-IN-1 environment. The most 
important change involves the separation of DEVELOPMENT from TEST. 

We owe our inspiration for recent work to one of Rick Warford’s DECUS sessions. Rick had explained that 
OA$LIB: "belongs to" DIGITAL and should be reserved for DIGITAL’s use. That started us on the search 
for an appropriate "where" for new and modified scripts, command procedures, and forms. He also told us 
about the OA$FILE_SEARCH_ORDER function, with which we had been unfamiliar. That was our first 
clue to an appropriate "how". Finally, Rick made us aware of the OAINI.SCP "script" script which runs 
after the MAIN menu displays. That helped to complete our concept of "how". 

The remainder of this article describes the approach we are currently testing. We are anxious to receive 
your comments about our methods. If you see problems or potential shortcomings or have suggestions 
otherwise, your reaction will be greatly appreciated. 

THREE LEVELS OF USE: 

We have three levels of use within ALL-IN-1: 

D DEVELOPMENT 
T TESTING 
P PRODUCTION 

Each user has been designated as ’D’ or ’T’ or ’P’ in the UFLAG10 field of his or her PROFIL record. The 
OAINI.SCP opens and then closes the form libraries appropriate for that category of user to assure that 
future access occurs in a pre-specified order. Only the two libraries actually used in production are left 
open, thus assuring that each type of user enters ALL-IN-1 in PRODUCTION mode. TEST and 
DEVELOPMENT users have options to turn their special libraries on, to set the appropriate file search 
order, and to reverse the TXL search order. 
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These THREE LEVELS are outlined next in some detail: 


1. DEVELOPMENT (by ALL-IN-1 MANAGER & PROGRAMMER) 

a) new and modified forms are developed in the 
0A$DEVLIB:DEVOAFORM library 

b) new and modified scripts and command procedures are 
developed in the 0A$DEVLIB: directory 

c) the OA$TXL_SEARCH_LAST order is reversed 

d) the 0A$FILE_SEARCH_ORDER is set to "OA$DEVLIB:,OA$TESTLIB 
0A$D0:,0A$M0DLIB:,0A$LIB:,0A$DATA:,[]" 

e) libraries are opened in this order: 

USER 

0A$LIB:MANAGER 
0A$DEVLIB:DEVOAFORM 
OA$TESTLIB:TESTOAFORM 
0A$M0DLIB:MODOAFORM 
OA$LIB:OAFORM 

2. TESTING (by a QUALITY CONTROL group of 12 users) 

a) new and modified forms that are ready for testing have 
been copied to OA$TESTLIB:TESTOAFORM from 
0A$DEVLIB:DEVOAFORM 

b) new and modified scripts and command procedures that are 
ready for testing have been copied to the OA$TESTLIB: 
directory from OA$DEVLIB: 

c) the OA$TXL_SEARCH_LAST order is reversed 

d) the 0A$FILE_SEARCH_ORDER is set to 

"OA$TESTLIB:,OA$DO:,0A$M0DLIB:,0A$LIB:,OA$DATA:,[]" 

e) libraries are opened in this order: 

OA$TESTLIB:TESTOAFORM 
0A$M0DLIB:MODOAFORM 
0A$LIB:OAFORM 

3. PRODUCTION (the whole user community) 

a) new and modified forms that have been approved for use by 
all users have been copied to 0A$M0DLIB:MODOAFORM from 
OA$TESTLIB:TESTOAFORM 

b) new and modified scripts and command procedures that have 
been approved for all users have been copied to the 
0A$M0DLIB: or 0A$M0D directories from OA$TESTLIB: 

c) the OA$TXL_SEARCH_LAST order is normal 
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d) the 0A$FILE_SEARCH_ORDER is set to "OA$MODLIB:,0A$D0:, 

OA$LIB:,OA$DATA:,[]" 

e) libraries are opened in this order: 

0A$M0DLIB:MODOAFORM 
OA$LIB:OAFORM 

COMPILING SCRIPTS: 

In order to separate new and modified scripts from the original versions and still be able to compile them 
for the production environment, we maintain an OA$ORIGDO: directory which contains all of the original 
OA$DO: scripts. To compile the TXL, we delete everything from OA$DO:, copy in everything from 
OASORIGDO:, and then copy in everything from OA$MODDO:, overlaying and replacing any original 
versions that exist. 

This same method applies to OA$BLP: and OA$SCP:, since they contain boilerplates and "script" scripts 
which are compiled as part of the TXL. 

However, boilerplates and "script" scripts are developed in OA$DEVLIB: and tested in OA$TESTLIB:. 
Because of the File Search Order and the reversal of the TXL Search Last order, newer versions will be 
"found" ahead of older, previously compiled versions. Thus, we feel it would be fruitless to maintain 
OA$DEVBLP:, OA$TESTBLP:, OA$DEVSCP:, and OA$TESTSCP: directories. 

OAFORMS & MEMRES: 

We anticipate no real need to recompile or reinstall the OA$LIB:OAFORM forms library as part of the 
forms modification process, since it will never contain anything blit the original "plain vanilla" forms. 

However, there is a very small number of new or modified forms which we must put in OA$LIB:MEMRES 
simply because they won’t work anywhere else. For example, we must put in MEMRES the screen which 
contains the options ufor switching between PRODUCTION and TEST or PRODUCTION and 
DEVELOPMENT modes. Otherwise, the user might easily end up closing the library which contains that 
screen! 

KNOWN PROBLEMS: 

Known problems with this approach have been few so far. 

The ALL-IN-1 MANAGER account will not initialize with the correct library sequence in spite of the fact 
that it seemingly goes through the exact same process other accounts go through. No account other than 
MANAGER has ever failed. Our concern is whether one could. The HOTLINE is working on this problem. 

Also, should a DEVELOPMENT user switch a number of times between DEVELOPMENT, TEST, and 
PRODUCTION mode, the library sequence can get out of sync. This problem is avoidable. 

ALL-IN-1 UPDATES & RELEASES: 

We hope to save a great deal of time, effort, and frustration when we install an update or new release of 
ALL-IN-1. By copying the new ALL-IN-1 files to appropriate OA$ORIGxxx directories and then laying our 
changes over the new ALL-IN-1 files in their normal directories, we hope to have a minimum of actual 
changes to make. 

Careful study of the documentation for the new release should help us determine what new options or 
modified functions we may need to revise our versions to include. 
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OA SIG TAPE: 

For your convenience, the files related to "3 HELPS" and to "YOURS, MINE, & OURS" can be found in 
the [.OA88A.BRUNER.AONEHELPS] subdirectory on the new OA SIG TAPE. 

CONCLUSION: 

We hope to maintain separation (and therefore control) over what is "YOURS" (DIGITAL originals), 
"MINE" (our originals), and "OURS" (modifications to DIGITAL originals) for forms, scripts, and com¬ 
mand procedures through use of the approach described in this article. 

By opening form libraries in a specified sequence and by setting the OA$TXL_SEARCH_LAST and the 
OA$FILE_SEARCH_ORDER, we plan to designate three different levels of ALL-IN-1 use at the Foreign 
Mission Board. 


APPENDIX: 

! OAINI.SCP 

.function get $syslogin=log$sys$login 
.function get #in = oa$date_nbs 
.FUNCTION DO OA$MODLIB:LIBSWITCH 
.function get tout = oa$date_nbs 

ABOVE: The OAINI.SCP runs after the MAIN menu displays. Here it performs a 
"do" script basically to establish the library access order (see 
LIB_SWITCH below). 

#IN and #0UT are local symbols used to capture the time at the beginning 
and end of this script. We use a "compute ttime = tout - tin" to 
calculate how long the procedure takes per type of user. That also 
allows us to test the effects of moudifications to the script coding. 

'k'k'k'k'k'k'kJck'k'klc'kltJt'k'k'k'kicic 


LIB_SWITCH.SCP 

oa$flo_close_lib oa$lib:oaform 
dump_cache 

get #lib_type= profil.uflaglO[oa$user] 

.if tlibtype eqs "p" then .goto p 

•if tlib_type eqs "t" then .goto t 

.if tlib_type eqs "d" then .goto d 

.goto p 
.label d 

get oa$function="oa$flo_open_lib " oa$profildirect "user" 
oa$flo_open_lib oa$lib:manager 
oa$flo_open_lib oa$devlib:devoaform 
oa$flo_close_lib oa$devlib:devoaform 
.label t 

oa$flo_open_lib oa$testlib:testoaform 
oa$flo_close_lib oa$testlib:testoaform 
.label p 

oa$flo_open_lib oa$modlib:modoaform 
oa$flo_open_lib oa$lib:oaform 
dump_cache 

get oa$file_search_order=- 
"oa$modlib:,oa$do:,oa$lib:,oa$data:,[]" 

.exit 


OA-6 





ABOVE: Pay particular attention to the libraries that are opened for each type 

of user. Notice also which ones are subsequently closed. This 
procedure is necessary to "cement" the library order for later use. 

Then the DEVELOPMENT and TEST users use options of the LIBMODE screen to 
place their account in the desired MODE. 


* * 'k'kit 'k^k'k'k * * * *k * * 'k'klck * * 


MY Manager Library On 

SETLIB MN Manager Library OffNM NEWLIB 

NM NEWLIB Manager Library 

OY Oaform Library On UY User Library On 

ON Oaform Library Off UN User Library Off 

NO NEWLIB Oaform Library NU NEWLIB User Library 

MOY ModOaform Library On SY Specific Library On 

MON ModOaform Library Off SN Specific Library Off 

NMO NEWLIB ModOaform Library NS NEWLIB Specific Library 

DY DevOaform Library On TY TestOaform Library On 

DN DevOaform Library Off TN TestOaform Library Off 

ND NEWLIB DevOaform Library NT NEWLIB TestOaform Library 

FST Set FILE SEARCH Testing DC Dump Cache 

FSD Set FILE SEARCH Development FLS Form Libraries Search 
FSP Set FILE SEARCH Production LL List Libraries Open 
FSO Show FILE SEARCH Order TXL 0 


ABOVE: Form SETLIB has been updated from "3 HELPS". It is used by 

DEVELOPMENT users only. See "3 HELPS" for more information as well as 
excerpts of Named Data from SETLIB. 


*** * * * * * ***** * * 'k * * ** * 

LIBRARY MODE MENU 

T TEST LIBRARY On Open Library: 

P PRODUCTION LIBRARY On PRODUCTION 

TXL1 Reverse Script Order 
TXLO Normal Script Order TXL Status: 

LL List Libraries NORMAL 

FSO File Search Order 


ABOVE: Form LIBMODE replaces form TLIB as described in "3 HELPS". It is used 
by both DEVELOPMENT and TEST users to switch back and forth between 
PRODUCTION and DEVELOPMENT or TEST mode. Entering 'T', 'D', or 'P' 
causes the proper libraries to be opened or closed, the File Search 
Order to be set correctly, and the TXL search order to be 
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established- 'D' is a "hidden option". See "3 HELPS" for more 
information and excerpts from the Named Data on LIBMODE (TLIB). 


$255$DUA8s[ALLIN1.LIB]MEMRES.FLB 5 

— -FLB open=l, .FLC open=l, Forms=47, Ref count=4 
$255$DUA4:[ROGERB.OA]USER.FLB; 

— -FLB open=l, -FLC open=l, Forms= 8 , Ref count=0 
$255$DUA8:[ALLIN1.LIB]MANAGER.FLB; 

— -FLB open=l, -FLC open=l, Forms=46, Ref count=0 
$255$DUA8:[ALLIN1.DEVLIB]DEVOAFORM.FLB; 

— -FLB open=0, -FLC open=0, Forms=0, Ref count=0 
$255$DUA8:[ALLIN1.TESTLIB]TESTOAFORM.FLB; 

— -FLB open=0, -FLC open=0, Forms=0, Ref count=0 
$255$DUA8:[ALLIN1.MODLIB]MODOAFORM.FLB 5 

— -FLB open=l, -FLC open=l, Forms=69, Ref count=0 
$255$DUA8:[ALLIN1.LIB]OAFORM.FLB; 

— -FLB open=l, -FLC open=l, Forms=407, Ref count=l 


Open libraries are indicated by '—-FLB open=l'. Press RETURN to continue. 


ABOVE: The OA$FBT LIST LIBTREE functions serves to monitor the access order and status of all 
form libraries within the current session (’LL’ option on SETLIB and LIBMODE). Above is a sample 
of output from this function for a DEVELOPMENT user upon initial entry into ALL-IN-1. Note that 
the libraries maintain their place in order in spite of whether they are open or closed. 

A*************** 


A SUMMARY OF OUR ALL-IN-1 DIRECTORIES: 

OA$LIB: OA$DO: OA$BLP: OA$SCP: 


OASORIGLIB: OA$ORIGDO: OA$ORIGBLP: OA$ORIGSCP: 
OA$DEVLIB: * * * 

OA$TESTLIB: ** ** ** 

A$MODBLP: OA$MODDO: OASMODBLP: OA$MODSCP: 


* OASDEVLIB is used 

** OA$TESTLIB 

is used 
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NEW SIG TAPE NOW AVAILABLE 


Roger Bruner, Foreign Mission Board 


The latest tape is an updated version of the OA SIG tape made available after the 1987 
Spring DECUS in Nashville. The previously released material is in directory [.0A86B]. 

Please note that some of the NEW material consists of updates and revisions to material 
in [ .0A86B]. 

The NEW material (April 1987 through February 29, 1988) is in directory [.0A88A] and 
includes the following subdirectories and topics. (For more specific and detailed in¬ 
formation, please refer to the AAAREADME.TXT in each directory/subdirectory.) 

Many thanks to the submitters from all of us in the OA SIG! 


I. [.BRUNER] 

(A) [.ANSWER FILE OR DELETE] 

(B) [.A ONE HELPS] 

(C) [.INTERFACE] 

(D) [.MULTIPLE ATTACH] 

(E) [.NEXT OR PREVIOUS] 

(F) [.QUEUE MANAGEMENT] 

(G) [.SYS DICT] 

(H) [.SYSUDP] 


An ALL-IN-1 script to enable the user to dispose 
of the Original mail message as part of the 
Answer procedure 

Contains articles "3 HELPS" and "YOURS, 
MINE, & OURS" and related forms, scripts, and 
command procedures 

An ALL-IN-1 application for controlling access to 
ALL-IN-1 functions, DCL commands, and external 
applications 

An ALL-IN-1 function to allow the contents of a 
selection list to be attached automatically to the 
current mail message (replaces previous MAIL 
FOLDER function) 

Two ALL-IN-1 functions for locating the next or 
the previous document in numeric sequence from 
the current document 

Four ALL-IN-1 functions which allow the users to 
specify a form name for printing, reset the queue, 
show queue, and delete a job from the queue 

An ALL-IN-1 facility for creating and using site- 
specific System Dictionaries 

An ALL-IN-1 facility for accessing User or System 
UDP’s 


Roger E. Bruner 

Foreign Mission Board, S. B. C. 

P. O. Box 6767 
Richmond, VA 23230 
(804)353-0151, ext. 606 

II. [.COY] 

(A) [.COLORS] A package for managing and setting "default" 

colors for VT-241 and VT-340 terminals (revision 
of previous version) 
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(B) [.DM$SD] 


(C) [.MAKE TLB] 

<D) [.MCL] 

(E) [.SHOWME] 

<F> [.VAXNOTES] 

<G) [.WPE] 

(H) [.WPELSE] 

Dale E. Coy 
E-8, MS/J957 

Los Alamos National Laboratory 
P.O. Box 1663 
Los Alamos, NM 87545 
(505)667-3270 


An extensive revision of the Hayre/Gregory 
Directory Management package (updated) 

A revision of Alan L. Zirkle’s SET DEFAULT pro¬ 
gram (updated) 

Procedures for making a DXC Compressed Text 
Library from all "text" files in a directory 

Two programs for producing multi-column listings 

Program which provides users with node, terminal, 
and process information 

Some useful things for systems running 
VAXNOTES 

A "complete" and extended implementation of 
WPSPLUS (TM) for editing ASCII files, including 
some language sensitive features for .COM files 

An implementation of WPSPLUS (TM) for LSE 


III. [.GILBERT] 

(A) A hierachical Employee Data phone 
[.EMPflirectory and database, which replaces 

"ALL" and "COR" phone directories 
under ALL-IN-1 

(B) [.LN03] A modification to the LN03.PRA file which 

enables printing 66 lines per inch in portrait orien¬ 
tation, fixes total line count error when using 8 
lines per inch, and will count lincorrectly when 
using "GOLD PAGE" (if down-line load fonts are 
available) 

(C) [,SWP] A Shared Word Processing System under ALL-IN- 

1 

Douglas L. Gilbert 
Boeing Aerospace Company 
P. O. Box 3999 M/S 85-04 
Seattle, WA 98124-2499 
(206)773-1795 


IV. [.IOELE] 

(A) [.A1CALCHK] An ALL-IN-1 function to allow a user to determine 

for a given day when one or more users have ac¬ 
tivities on their own calendars 

Tony Ioele 

Technical Software Specialist 
ARA Services, Inc. 

The ARA Tower 
1101 Market Street 
Philadelphia, PA 19107 
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(215)238-3629 

.LEDERMAN]* 


(A) 

[.ACCOUNTING] 

Programs to convert System Accounting and PS I 
Accounting data to a normalized form readable by 
DATATRIEVE and other languages with record 
definitions 

(B) 

[.ALLIN1] 

Contains DTR definitions to work ALL-IN-1 log¬ 
ging and data files; document database also works 
with WPSPLUS/VMS (revised) 

<c> 

[.CORPHONE] 

DTR replacement for ALL-IN-1 corporate phone 
directory 

(D) 

[.FUNCTIONS] 

User defined functions; DTR procedures for cata¬ 
loging, defining, and generating functions 

(E) 

[.NEWSLETTERS] 

Past issues of the Wombat Examiner Newsletter 

(F) 

[.PLOTS] 

Additional PLOTS and articles on adding your own 
plots 

(G) 

[.RECALL] 

Uses SMG to provide command line recall in DTR; 
plus DAB definitions in "C", Macro-32 

(H) 

[.RSX ACCOUNTING] 

Process RSX-11M-PLUS system accounting and 
RSX console logs with DTR 

(I) 

[.SESSIONS] 

Transcriptions of some Symposia sessions 

(J) 

[.SIXEL] 

A program to convert ReGIS to SIXEL 

(K) 

[.SYSMGR] 

Bart Z. Lederman 

WU World Communications 

67 Broad St. 28th floor 

New York, NY 10004-2464 
(212)607-2657 

DTR definitions for Disk Quotas, SYSUAF, etc.; 
procedures to record user login history and ter¬ 
minal /line usage 


♦Bart’s submissions are also part of the DATATRIEVE/4GL SIG Library Collection (V-SP-59). 
Because of the relevance of this material to Office Automation, he was asked to share with the 
OA SIG as well. 

VI. [.ROTH] 


(A) 

[.LG02] 

Allows use of available fonts resident in LG02 line 
printer with ALL-IN-1 

(B) 

[.PENDING] 

Shows ALL-IN-1 PENDING file by user-specified 
number of pending messages 

(C) 

[.RMN] 

An ALL-IN-1 Multiple Read for mail which allows 
users to read new mail sequentially and answer, 
print, or delete it as they read 

(D) 

[.TMPRINT] 

Allows ALL-IN-1 user to specify a window of time 
(rather than the 24 hour default window) for print¬ 
ing week’s schedule and calendars 

(E) 

[.TODO] 

Sorts "to do" list in ALL-IN-1 by priority and 
number; results may be displayed or printed 
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Trace G. Roth 

O. H. Materials Corp. 

16406 U.S. Route 224 East 

P. O. Box 551 

Findlay, Ohio 45839-0551 
(419)423-3526 

THIS TAPE HAS BEEN COMPILED BY : 

Roger E. Bruner 

Baptist Foreign Mission Board 

P. 0. Box 6767 

Richmond, VA 23230 

(804)353-0151 
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CHAIRMAN S COLUMN 
By Lynn Jarrett, PC SIG Chair 

Here it is—time for another great DECUS symposium—and the PC SIG is raring to go. 

The sessions by the SIG this month are yet another round of excellent offerings by Digital Equipment and 
Digital Equipment users as well as some other '’outsiders” who are entering the world of Digital and its 
customers. 

The PCSA sessions are a great mix of varying degrees of technical expertise and interest ranging from a user 
panel on the subject to a "Configuration Considerations for Better Performance” session. There will also be 
sessions on MS-Windows. We are just offering attendees more of the same of what they have requested from the 
last symposium. 

Additionally, there will be some very interesting VAXstation sessions of interest across several SIGs within 
the user community. Mark Sebern of Sebern Engineering, a member of the PC SIG, is giving several of these 
sessions and we welcome him bringing his technical expertise and assistance back to Symposia again and again. 

From the Macintosh world, we are pleased to have the president of Pacer Software, Garth Conboy, present a 
session on the Mac to VAX connection, and I'm sure that our keynote speaker. Bob Soucy of Interleaf, will give an 
outstanding presentation in his session on the use of desktop publishing applications in the Macintosh and 
VAXstation world. 

Sessions on the Rainbow, PRO and the DECmates are also going to be of interest to many DECUS attendees and 
I’m sure these sessions will be well attended by all, as usual. 

During the week of Symposia, our SIG puts on an excellent Magic session, hosted and chaired by our own Fritz 
Howard, (VAXmate Working Group Chair), and it is always a resounding success. Users get together and share 
war and horror stories, and it’s a most fun event. Following Magic, we host a party in the SIG suite that is 
always a popular event at DECUS with attendees from many SIGs, at which prizes are awarded for the 
winners of Magic. 

Digital Equipment Corporation has been most supporting of the PC SIG, and we are grateful to counterpart 
Anita Uhler from the PCSG group, and to Jeff Slayback, our PRO counterpart, for all their support and 
assistance in their work with this SIG. Without them and our troop of great volunteers, this SIG wouldn’t 
exist. 

Hopefully you may make it to DECUS and visit our Campground with all the equipment we have to display 
and to try out if you like. The vast array of different devices and software represents the varying interests and 
uses of equipment that is supported within the PC SIG. These devices include a VAXmate, Rainbow, PRO, 
VAXstation 2000, Macintosh, and more. They also will be networked to their own MicroVAX using via PCSA. 
And you may be surprised as to the software that will be running on these machines. 

Jim Hobbs is our excellent Campground Coordinator and I want to thank him here for his outstanding job in 
gathering all of this hardware and software together so that symposia attendees can gather together and enjoy 
the use of the equipment as well as a meeting and "camping out” place. 

Jimbo Wilson, our new Symposia Coordinator, has done an excellent job of putting together the sessions, 
recruiting both the session speakers and session chairs and a lot of behind the scenes work that has to be done by 
the person in this position. And on behalf of the entire SIG, I want to thank him for all his work in this area as 
well as the assistance he gave to Jim Hobbs in his role as Campground Coordinator. 

Ken Strieker, our button and art coordinator, and a new volunteer in our organization, worked hard to get our art 
work ready for the T-shirts being sold in the DECUS store as well as the art for all the buttons and the 
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Volunteer mugs and this work was appreciated by all. 

Another new volunteer who has come on board with us is Tim Bundrick, our new seminars representative, and 
his work in this area is going to prove to be extremely valuable to us and DECUS. 

Our newsletter editor, Gary Rice, is doing a lot of work behind the scenes what with editing the material he 
gets for the newsletter (I don’t know what we'd do without him), as well as producing several articles himself, 
and, additionally, serving as a moderator on DECUServe. Many thanks to Gary for a great job. 

Another behind-the-scenes job that may go unnoticed by many, but certainly not by the SIG steering committee 
and the buyers of the session notes is that of our Session Notes Editor. Tom Warren has been serving in this 
position for a year now and is doing a great job. 

Other hard workers in our SIG include Tom Hintz, VAXstation/PRO/MAC Working Group Chair and Vince 
Perriello, Rainbow/Decmate Working Group Chair. They recruit sessions and speakers or DECUS and field a 
lot of calls from the users in their area of expertise. Also, too, thanks to Ken LeFebvre for his representation of 
the PC SIG on the Comm Comm Committee. A lot of work goes on here on behalf of the newsletter. 

We are always looking for additional volunteers and still have some steering committee positions available. 
We welcome anyone who wants to join our team. I have to say it’s a fun team of which I’m proud to be a part. 
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PRO/TOOL KIT FORTRAN-77 V5.0/V5.2 COMPATIBILITY PROBLEMS 
By Digital Equipment Corporation 

With the release of PRO/Tool Kit FORTRAN-77 V5.2, two problems have been encountered. 

1. The vectored entry points into the resident library, are different between V5.0 and V5.2. Because of this, 
tasks built with V5.2 will fail or function improperly if they are run on a system that does not have V5.2 OTS 
installed. 

2. A problem in the Task Builder caused the V5.0 Library to be built improperly. This problem causes tasks built 
with V5.0 to be un-installable on a system that has V5.2 installed. 

To correct these problems, follow the procedure below after PRO/Tool Kit FORTRAN-77 V5.2 is installed. 

1. Log into a privileged account on the PRO. 

2. Enter the PRO/Tool Kit application. 

3. At the "$" prompt. Enter the following three commands: 

$ RENAME LBO:[1,5]PROF77.TSK LB0:[1,5]F77V52.TSK 
$ RENAME LBO:[1,5]PROF77.STB LB0:[1,5]F77V52.STB 
$ COPY LB0:[1,5]F77V52.TSK LB0:[ZZSYS] 

This will give unique names to the files supplied with PRO/Toolkit Fortran V5.2. 

4. Place the diskette labeled 

PROUTILV2 for P/OS V2.0 or V2.0A systems, 

PROLIBRV30 for P/OS V3.0 or V3.1 systems, or 
PROLIBRV32 for P/OS V3.2 systems 

into diskette drive 1 and enter the following command: 

$ COPY DZ1 :[ZZSYS]PROF77.TSK LBO:[ZZSYS]PROF77.TSK 

This places the V5.0 OTS into [ZZSYS] so that applications built with V5.0 will continue to operate 
correctly. 

5. The system should now be re-booted. 

TASK BUILD COMMAND FILE MODIFICATIONS 

The task build command files for programs using PRO/Tool Kit FORTRAN-77 should be modified to change the 
cluster library references from PROF77 to F77V52. Using an editor modify the line that begins: 

CLSTR=PROF77, 

to read 

CLSTR=F77V52, 

You should now task build the program with the renamed V5.2 files. 

INSTALLATION COMMAND FILE MODIFICATIONS 

If the program has a .INS and/or a .INB file, they should be modified as described below. The V5.2 OTS must 
be placed on the application diskette, so that the application can be run on a system that does not have 
PRO/Tool Kit FORTRAN-77 V5.2 installed. 
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• For a .INS file, add the following lines 

FILE [ZZSYS]F77V52.TSK/KEEP 
INSTALL [ZZSYS]F77V52.TSK/LIBRARY 

• For a .INB file, add the following lines in the appropriate locations: 

FILE [ZZSYS]F77V52.TSK/KEEP/CLUSTER 
INSTALL [ZZSYS]F77V52.TSK/LIBRARY/CLUSTER 

You should now use the Application Diskette Builder to re-build the application diskette(s). If you do not use 
ADB, then make sure that you place a copy of F77V52.TSK in directory [ZZSYS] of the appropriate diskette. 


PROgramming Quickie - Reading the TYPEAHEAD Buffer 
By Gary Rice, PC SIG Newsletter Editor 

In the March '88 issue, the PROgramming Quickie detailed how to "fake" an AST in FORTRAN. One of the 
problems with that program sample was its inability to process the QWERTY keys properly. This was caused 
because the program had no way to know how many characters were waiting to be processed. The QIO call that 
was used expected a particular character to signal that the last character had been read. That character was 
NOT one of the QWERTY characters. 

To allow literally ANY keystroke to be honored as an "AST" trigger, it is necessary to know how many 
characters to read. To find out, it is necessary to examine the contents of the TYPEAHEAD buffer. 

You can use the knowledge of what is in the TYPEAHEAD buffer for other things as well. For example, EDT 
examines the TYPEAHEAD buffer to avoid displaying things unnecessarily. Synergy does the same thing. 

This month's Quickie illustrates how to find out if anything is in the TYPEAHEAD buffer and if there is, it 
reads the contents into a program buffer. 


C TYPAHD.FTN - This program reads the contents of the TYPEAHEAD buffer 
C 

C ORIG VERS: 1.0 

C 

C CURR VERS: 1.0 
C 

C AUTHOR: Gary Rice 

C 

C CREATED: March 6,1988 

C 

C REVISIONS: None 
C 

C INPUTS: None 

C 

C OUTPUTS: None 

C 

C NOTES: None 

C 

£********************************************************** 

C 

PROGRAM TYPAHD 


C 
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c 

BYTE BUFFER(36), CHARS(2) 

C 

INTEGERS PARM1(6), PARM2(6), STATUS(2) 


A call to the system WAIT routine will allow you to actually put something 
into the TYPEAHEAD buffer so you can retrieve it 

CALL WAIT (2,2) ! Wait for 2 seconds 

The TYPEAHEAD buffer is queried via a call to the terminal driver's "Get 
Multiple Characteristics" (SF.GMC) function 

CALL GETADR (PARM1(1),CHARS) ! Get the addr of the CHARS buffer 
CHARS(l) = "71 ! Set the "TC.TBF" bit 

PARM1(2) = 2 ! CHARS is 2 bytes long 

Issue the "Get Multiple Characteristics" QIO on LUN #5 
CALL WTQIO ("2560,5,5„STATUS,PARM1) 

IF (CHARS(2) .EQ. 0) GOTO 999 ! If zero, the TYPEAHEAD buffer is empty 

C 

C Set up to READ the TYPEAHEAD buffer using the "Read passing all data bits" 

C form of the QIO 

CALL GETADR (PARM2(1),BUFFER) ! Get the program buffer address 
PARM2(2) = CHARS(2) ! Tell QIO how many bytes are waiting 

PARM2(5) = 1 ! Read only "block 1" 

CALL WTQIO (”1010,5,5„STATUS,PARM2) ! Do it on LUN #5 

999 CONTINUE 
END 


The command file that I used to link this program is as follows: 

TYP AHD/CP / FP=TYP AHD 
LB:[l,5]PROF77/LB 
/ 

; EQUATE P/OS SYMBOLS TO LUNS 

GBLDEF=TT$LUN:5 

GBLDEF=WC$LUN:0 

GBLDEF=MS$LUN:4 

GBLDEF=FL$LUN:0 

GBLDEF=HL$LUN :0 

GBLDEF=MN$LUN:0 

; DEFINE EVENT FLAG 

GBLDEF=TT$EFN:1 

; DEFINE CLUSTER SCHEME 

CLSTR=PROF77,POSRES,RMSRES:RO 

// 


Send me your own PROgramming Quickie and I will publish it here in this on-going column in these 
Newsletters. (RX50 Please) 
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An Introductory Guide to the Professional 300 Video Bitmap 

By Thomas R. Hintz, S. Sachs and Kefeng Chen, Institute of Food and Agricultural 
Sciences, University of Florida 

Introduction 

1.1 Intent 

The Professional 300 computer has proven to be an excellent graphics workstation. The use of GIDIS graphics is 
straight forward and easy to use, CORE graphics is only slightly more complex. However, to take full 
advantage of the graphics capabilities of the PRO requires a knowledge of directly addressing the bitmap. 
The intent of this document is to provide an introductory explanation of the workings of the PRO/300 screen 
bitmap. This information was accumulated through trial and error as a result of our need to improve the 
graphical performance and capability of our programs. 

While I try to explain some of the arcana known as ’’mapping to the I/O page”, I can’t say why certain things 
work the way they do. This is because I either have not been able to find it referenced in the plethora of 
documentation (see appendix A), or maybe it has not been documented. Consequently, some of the information 
provided is based on experimentation. 

Although quite a bit of technical information is provided textually, some things are more easily demonstrated 
than explained. Therefore, the source code for several graphics demonstration programs that manipulate the 
contents of the bitmap are also available (see appendix D). Reference to these programs are made throughout 
this document. The last chapter of this document provides instructions for various actions that can be performed 
with the programs. If you are interested in a copy they can be obtained by sending four RX50 diskettes and a 
self-addressed stamped envelope to the author. 

1.2 Hardware Requirements 

The documentation and sample programs assume that you have a PRO/350 with an Extended Bitmap Options 
card and a color monitor. However, if you have a different configuration, you should still find enough 
information in this guide and the noted references to deduce the proper manner for playing with your system. 

If you have a PRO/380, you will need to refer to the Professional 300 Series Technical Manual for the proper 
bitmap addresses for your machine. 

1.3 Languages 

Most bitmap accesses require 1 APR (active page register), while the fancier screen saves/restores from a region 
or file requires 3 APRs. Since a task has allocated to it 8 APRs (each APR may address 4kw, hence 8x4 = 32kw, 
the maximum task size), each APR used by you leaves less room for your own code and data. (Note that high- 
level languages like FORTRAN and PASCAL require at least one APR for their run-time libraries). 

For this reason, the bitmap manipulating code is usually written as a MACRO task, and other tasks (of any 
language) can then spawn the MACRO task. Or, if your needs are simple, you might just write the whole 
program as a single MACRO task. 

If your application is not large or is well overlaid, you may get by with a higher-level main routine with 
high-level subroutines and MACRO subroutines to handle the bitmap. In most cases, you will be restricted to 
MACRO bitmap-handling routines unless you can wring its addressing modes out of PASCAL or C. 

The sample programs available from the authors use MACRO subroutines to access the bitmap. This was done 
so that the subroutines may be used with just about any high-level language. This is a lot easier than writing 
the same routines two or three times in different languages. 
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1.4 What is the Bitmap 

The bitmap is the region of PRO memory set aside to contain all of the information necessary to display 
everything that appears on the monitor screen, which may include text and/or graphics. This region also 
indicates the color of every pixel that makes up the text and graphics in the display. 

The PRO comes with one plane of the bitmap. This allows the computer to display either black or white text 
and graphics. No shades of grey are possible with only one plane. 

1.5 The Bitmap Options Card 

Available separately, the addition of the extended bitmap options card (EBO) provides two more bitmap 
planes, thereby allowing shades of grey on a monochrome monitor and color on a color monitor. 


THE BITMAP 

2.1 Partition and Region 

The bitmap video (BMV) memory occupies a partition called BITMAP, and the system video handler creates a 
region called TFWBMP (terminal firmware bitmap) to fill it. 

• A partition divides the physical memory into separate,distinct work-areas for handling by a 
particular processor or controller. A task may specify the partition it wishes to access. The 
typical application resides in and makes use of the GEN (general) partition. 

• A region is a portion of physical memory within a partition to which a task has access. The task 
may read or write (depending upon the privilege bestowed upon the region by its creator) any 
data it wishes to a region. 

BITMAP is set up in such a way that another application can also attach to the region TFWBMP and map to all 
or a portion of it. Or, an application can use certain registers provided by the BMV (discussed in Chapter 3) to 
manipulate this region data. 

If your application simply attaches to the TFWBMP region, the application can read and write to it; however, 
this limits the images appearing on the screen to whatever the current attributes are. If you wish to draw with 
different colors, for example, you must set and pass data through the BITMAP registers. The demonstrations 
and discussions in this document refer to the more structured approach of manipulating the bitmap data via its 
provided registers. 

The BMV data is the first 30kb of the 32kb associated with TFWBMP. The least significant portion of the first 
word of the region corresponds to the upper left corner of the screen. 

If there is an EBO in the system, all three planes of memory share the same 32kb bus address space; the plane 
you wish to access is specified at the time the request or data is sent. 

2.2 Video Resolution 

The video hardware normally displays an image with a resolution of 1024 by 240 pixels (1024 times 240, 
divided by 8 is 30kb of data) per provided plane. This means that a non-EBO system displays black or white 
pixels only (pixel on/off), and an EBO system can display eight colors or grey levels at a time (pixel on/off for 3 
planes = 2x2x2 = 8 colors); black (pixel off) is included as a color in the above calculations. 

If you reduce the horizontal resolution from 1024 to 512 pixels, two memory bits control each pixel; the pixels 
are displayed twice as big by the video controller and each pixel can now have four grey levels for a 
monochrome system or 64 colors in a color system. 

Further reduction of resolution from 512 to 256 pixels yields four memory bits per pixel; the pixels are now 
displayed four times as big as compared to the 1024 mode, and 16 grey levels or 4096 colors may be specified. 
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Note: This reduction of resolution to provide more colors is also known as "folding the bitmap.' 


Horiz 

Pixel 

Each 

Monochrome/ 

Total 

Total 

Pixel 

Size 

Bit 

Color Values 

Mono 

Color 

Res. 


Controls 

per Plane 

Choice 

Choice 

1024 

1:1 

1 pixel 

0-1 0-1 0-1 

2 

8 

512 

2:1 

2 pixels 

0-3 0-3 0-3 

4 

64 

256 

4:1 

4 pixels 

0-15 0-15 0-15 

16 

4096 


Table 2-1 Horizontal Resolution and Associated Color Values 

Note: Monochrome grey scale is determined by the BMV controller based upon plane values; while you have as 
many choices as for color, the controller will round to the nearest grey-scale. 

Note: (1024 x 1) = (512 x 2) = (256 x 4). The 1, 2, and 4 come from the "Each Bit Controls" column. 


THE BITMAP REGISTERS 
3.1 Introduction 

Normally, you use the provided graphics libraries (CORE Graphics or GIDIS) to draw on the screen, and text is 
placed on the screen via print or write statements. 

If you wish, you may bypass the above libraries and handle all bitmap manipulations yourself. This is more 
primitive than CORE or GIDIS in that if you want to draw a line, you must set all of the pixels for the line 
yourself, for example. 

All communication with the BMV is performed through certain system- maintained registers. With these 
registers, you may place data into and read data from the bitmap. 

WARNING 

Improper use of the video registers may crash your system. 

If you try to compete with P/OS in accessing the BMV, you 
will lose. You must plan this out so that your application 
does not access the registers at the wrong time or try to 
dictate the use of the registers for other applications you 
did not write. 


Note 

"Crashing your system" as mentioned above only means that 
you will have to turn the PRO off to clear memory; toying 
with the BMV does not harm your hardware. 

Note 

Because register access of the BMV bypasses the provided 
methods for drawing to the screen, neither Print Screen, 
GIDIS, nor CORE graphics will be notified of any access or 
manipulations your program may perform. Therefore, 
subsequent use of the above mentioned items may produce 
unknown results until the screen is fully cleared (like with 
a terminal-reset escape sequence). 


PC-8 



3.2 Where Are the BMV Registers? 

A task cannot just start playing with the BMV registers. You must tell the system what you plan to do. 

Normally, a task's data will be placed in and region-mapping will occur in the (default) GEN partition. You 
must indicate that you want read/write access to the BITMAP partition. 

Also, the BMV registers do not reside within your task's reach as, say, registers 0 through 7 are to a MACRO 
programmer. You must indicate that you are going to use the BMV registers that are located along the BMV 
control bus. 

In the PRO'S CTI (Computer Terminal Interconnect) architecture, as on other PDP-11 buses, devices are 
controlled via device registers which appear as memory in the top 8 kb (the 1/O page) of the bus address space. 
Note: 4 kb of ROM is in the I/O page, so only 4 kb out of the 8 kb is potentially writable. 

The 1/O page addresses extend from 17760000o through 17777777o. (This is 4096o words or 8 kb.) 

Unlike those on UNIBUS and the Q-bus devices, the device registers on a CTI device do not have fixed 
addresses on the bus. Instead, each option slot has a 128-byte device register address space, the location of 
which can be found in the table below: 

Slot 1/O Option Slot Page Addresses 
0 17774000-17774177 

1 17774200-17774377 

2 17774400-17774577 

3 17774600-17774777 

4 17775000-17775177 

5 17775200-17775377 

Table 3-1. PRO/350 Option Slot Addresses 

Note: Addresses are in octal. While slots 0-7 may be mentioned, there are only 6 physical slots (0-5) 
available. 

The registers for a given module will appear at the fixed displacement within the address space of the slot the 
module is in. 

The registers associated with the bitmap are for the plane 1 bitmap card that comes with all PROs. Even if 
you have an EBO, you will still send your instructions through the plane 1 bitmap card registers; the system 
will handle accessing the EBO card. 

Therefore, before you can access the BMV registers, you need to know what slot the plane 1 card is in. In this 
manner, you can determine the slot address. You may then access the registers through the resident common 
CTPAGE, which covers the I/O page for each slot. CTPAGE contains readable and/or writable data; the BMV 
slot registers are a part of this data: 

I/O Page (CTPAGE Region), 8 kb 
17760000... 17774000 -177775377... 17777777 

14000o bytes 1400o bytes 2400o bytes 

slot registers 

14000o + 1400o + 2400o bytes = 20000o bytes or 8 kb. 

Figure 3-1. I/O Page/CTPAGE Region Layout 
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3.2.1 SLOTTEST 

The SLOTTEST program searches for the bitmap card by examining each slot in the card cage until it finds a 
card ID of 1002o (the BMV card's ID). The actual subroutine that performs the search is called IDSLOT 
(compares slot ID's), and it is used by other demo programs. 

SLOTTEST maps APR 5 to CTPAGE in order to gain access to the 1/O page. 

Note 

To recap, this means we will be accessing the bitmap data 
through the bitmap registers; the bitmap registers are in 
the CTPAGE region. Therefore, we are NOT attaching to or 
manipulating the TFWBMP region data directly. We are 
letting the registers handle the TFWBMP data. 

3.3 Mapping to the Bitmap Video Control Registers 

Once you have determined the BMV slot, you can map to the video controller registers (VCRs) through an APR. 
The APR you use may be arbitrary if your task is all in MACRO; if you use a higher-level language, you must be 
aware that the lower APR values are usually used by the run-time libraries (for run-time error posting, file 
I/O, etc.). 

The sample programs all use APR 5 to map to the VCRs since that APR seems to be relatively free -- as long as 
you don't have so much code or data that that APR is necessary. 

As you can see, this is a matter of trial and error. 

Anyway, to map to the VCRs, you need to calculate an address using the slot address and the APR. Each APR 
can access a certain virtual address, as listed below. 

APR Virtual Address 


No. 

Range 

K Words 

0 

000000 - 017777 

00-04 

1 

020000 - 037777 

04-08 

2 

040000 - 057777 

08-12 

3 

060000 - 077777 

12-16 

4 

100000 -117777 

16-20 

5 

120000-.137777 

20-24 

6 

140000-157777 

24-28 

7 

160000-177777 

28-32 


Table 3-2. APR and Virtual Address Correspondence 
Note: Addresses are in octal. 

To get the VCR base address, use the following formula: 

(a) Remove the leading "1777" from the slot address and replace it with "1". (This is done to turn the 
22-bit address into a 16-bit address.) 

(b) Add octal value from (a) to the beginning APR virtual address range. 

If, for example, the BMV card was in slot 2, and APR 5 is to be used, (a) would be 14400 and (b) would be 14400 + 
120000=134400. 

If a program were to use APR 4 and slot 2, (a) would be 14400 and (b) would be 14400 + 100000 = 114400. 

Your choice of APR will typically not change from one run to the next, so this value is usually put in code as a 
constant. 
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Note 

You might think that the higher the APR, the "closer" that 
APR's address should be to the CTPAGE region that’s sitting 
in the top 8 kb of memory, and hence the calculated APR and 
slot address figure should be getting smaller. But as you 
can see, using APR 5 gives you a figure (134400) that’s 
higher than if you used APR 4 (114400). So, you might think 
that the APRs are lined up in reverse or something. This is 
not true, either. 

Actually, I could not find an explanation anywhere that 
stated why these numbers are used this way at all; but, they 
were always used this way. If you want some conjecture, I 
say that offsets to the CTPAGE region are determined from 
the APR 0 address, and that maybe you add higher offsets as 
the APRs increase (as if to make up for the offset back down 
to APR 0 and then to the CTPAGE adddress). Of course, this 
sounds strange, and if someone will direct a clear explanation 
my way. I'd be glad to add it to this document. 

The BMV card address, on the other hand, may be coded as a constant if the program you are writing is for a 
machine whose BMV slot you already know, or it may be determined during run-time as in the SLOTTEST 
program. Be aware that the BMV and EBO cards may be in any slot, so if you wish to write an application for 
others to use, do not make assumptions. With the routines in the demo programs, it is not that difficult to 
search for the proper slot. 

Having determined the VCR address, you must map a part of your task (the part whose APR you specified) to 
the CTPAGE so that you can access the registers. There are two ways to map to the CTPAGE, and so two demo 
programs are available. 

3.3.1 TASK-BUILT CTPAGE ACCESS 

You may have access to the CTPAGE built into your task so that when the application is run, the system 
performs the mapping "automatically'' for you. AUTOCT demonstrates this procedure. Note: Since the proper 
mapping is built into the task data itself, you must determine the slot and APR beforehand. 

The procedure to follow is to have two tasks. Task 1 is your regular task with code and data; Task 2 is a task 
that will be loaded into the CTPAGE region. 

Applications using this method usually have a small task named CTPAGE that consists of the following (this 
is CTPAGE.MAC in the demo): 

APR = 5 ; Place APR value in a constant (symbol). 

. = 0 ; Start assembling at memory addr. zero. 

.blkb <APR*20000>+14400 ; Assume slot 2. 

.even 

...global VCR list... 

.end 

Notice that this method assumes the BMV card is in slot 2 and hence cannot be altered during runtime. The 
<APR*20000> is evaluated when the MACRO routine is compiled, and the value comes out to the proper 
120000o value for APR 5, which is then added to the altered slot 2 address (14400o) to yield 134400o. The 
".blkb" instruction tells the MACRO compiler to provide 134400o bytes for storage; this storage space will 
eventually be overlaid upon the CTPAGE region to encompass all data within it up to and including the slot 2 
data registers: 
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<- I/O Page (CTPAGE Region), 8 kb ~> 

17760000... 17774000 -177775377... 17777777 
0 ...1 ...2... etc 
slot registers 

<- CTPAGE.TSK region -> 

<- AUTOCT.TSK window -> 

Figure 3-2. AUTOCT Mapping to CTPAGE 

As you can see, your CTPAGE.TSK's region must be large enough to lay over the data preceding the slot 2 
registers; you will then use only that part of the region coinciding with the slot 2 registers and ignore the rest. 

CTPAGE.CMD, the linker command file for CTPAGE.MAC, instructs that the task be built without a stack 
(since it is just data — no code). A portion of CTPAGE.CMD is listed: 

STACK = 0 

PAR = CTPAGE:120000:20000 

120000o indicates the byte address of the start of the CTPAGE partition. The 20000o is the number of bytes 
contained in the partition (or at least the portion thereof you wish to access). 

The linking of CTPAGE will produce two files: CTPAGE.TSK and CTPAGE.STB (the symbol table file that 
includes the global label names listed in CTPAGE.MAC). 

The main task, AUTOCT, includes the following lines in its linker command file: 

WNDWS =1 

RESCOM = CTPAGE/RW:5 

WNDWS declares the number of address windows required by the task (in addition to those normally needed to 
map the task image). RESCOM indicates the region to be mapped (widowed) to, its type of access 
(read/write), and the APR to be used in this mapping. (The linker also assumes that there is an .STB file with 
the same name as the region specified in the RESCOM line.) 

Once all of this has been set up, the task can simply start using the VCR variables listed in the CTPAGE.MAC 
file. 

To create the AUTOCT task yourself, first compile and link the CTPAGE task. Then, compile and link the 
AUTOCT task. When AUTOCT is linked, the linker will pull the CTPAGE.STB data into the AUTOCT task 
image. Therefore, after everything is linked, you may discard the CTPAGE files. Do not try to install or run the 
CTPAGE task; install and/or run the AUTOCT task instead. 

Note: While it is confusing to call your own task/region CTPAGE while trying to discuss the system's CTPAGE 
region, the name CTPAGE is required for proper I/O page access. 

3.3.2 RUN-TIME CTPAGE ACCESS 

If you will only be writing bitmap programs for your own PRO, you can get by with the task-built CTPAGE 
procedure explained above. However, if you wish to distribute your application for others to use, you cannot 
assume the slot in which the BMV will reside, nor can you distribute your code and expect others to alter and 
link your tasks. It would also be bad form to create 8 versions of your task, one for each slot, and have the user 
try each until something works. 

The easiest manner for resolving this problem is to determine the BMV slot during run-time and then perform 
the subsequent map to the CTPAGE yourself. 
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RUNTCT demonstrates how to map to the CTPAGE during "run-time." The program's output is identical to that 
ofAUTOCT. 


Like AUTOCT, RUNTCT must create a window within CTPAGE that it can access. RUNTCT's window could 
have been made smaller, but since that would require some additional explanations (I could probably do it but 
not explain why it worked that way), it was left as large as AUTOCT's. (Again, if anyone can set me straight 
on this matter, please do so!) 

Remember, the slot may vary, because RUNTCT gets the slot information and maps to the proper portion of 
CTPAGE during run-time. 

To create the RUNTCT task yourself, compile the elements and link. You do not have to install the task before 
running it. 

RUNTCT uses the subroutine MAPCT to map to the CTPAGE at the indicated slot and with the given APR. The 
GETREG routine reads the contents of the readable registers. 

3.4 What Are the BMV Registers? 

The above demo programs showed how to access the BMV registers in the CTPAGE region. This section will 
discuss what each of the registers do. (Note: A complete explanation of the registers can be found in the PRO 
300 Series Technical Manual.) 

The bitmap is in "mapped" mode when the color map is enabled (via CSR bit 10). If the color map is disabled, 
then the bitmap is said to be in "unmapped" mode. The mapped/unmapped state affects how certain register 
contents are used by the BMV; the relationship is between colors and resolution. 

Note: It does not matter what you place into the "reserved" bits in writable registers. The system will ignore 
what you set there and probably replace it with its own values. The demonstration programs usually place 
zeros in the reserved bits. 

3.4.1 (IDR) IDENTIFICATION CODE 

The Technical Manual states that this register contains the card I.D., which for the BMV card is 1002o or 514d. 
However, I have actually found it to contain 177402o (-254d) on several PROs. Read only. 

3.4.2 (RES) RESERVED 

The contents of this register should not be read or written to (though reading it appears to be safe, if 
unnecessary); the purpose of its contents are unknown. However, a word of storage must be allocated to preserve 
the space this register occupies. 

3.4.3 (CSR) CONTROL STATUS 

This register controls the general operation and video timing of the BMV controller and the extended bitmap 
module. The register has the following bits: 

Bit Operation R/W 

0 Line mode (interlaced/nonint.) R/W 

(0 = 525/526,1=625/626) 

1 Interlace mode definition R/W 

(0 = off, 1 = on) 

2 reserved 1 

3 reserved 2 

4 reserved 3 

5 Odd/even frame definition R 

(0 = scan odd lines, 1= even) 

6 End of frame interrupt enable R/W 
(0 = disabled, 1= enabled) 
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7 End of frame definition R 

(1 = performing vert, retrace) 

8 Class of operation def. 1 R/W 

9 Class of operation def. 2 R/W 

(indicate ops. to perform) 

10 Color map enable definition R/W 

11 reserved 1 

12 reserved 2 

13 Option module presence def. R 

14 Done interrupt enable def. R/W 

15 Transfer done definition R 


Table 3-3. Control Status Register Bits 


3.4.4 (PIC) PLANE 1 CONTROL 

This register defines a logical operation, or update modification, to be performed on the plane 1 video memory. 
Read/write. 

Bits 0-2 contain information regarding the movement of bit patterns to screen memory. 

Bits 3 and 4 indicate the horizontal resolution: 00b = 1024,01b = 512,10b = 256, and lib = turn display off. 

Bit 5 indicates whether the system perform reads or writes to plane 1 memory. Set bit means access permitted, 
cleared bit means access denied. 

Bits 6-15 are reserved for system use. 

3.4.5 (OPC) PLANE 2 AND 3 CONTROL 

This register defines the logical operation, or update modification, to be performed on the plane 2 and 3 video 
memories. Read/write. 

The bit definitions for this register are identical to those of the plane 1 register. The bits themselves are as 
follows. 

Bits 0-5 are identical in function to the plane 1 register bits, except these are for plane 2 memory. 

Bits 8-13 are identical in function to the plane 1 register bits 0-5, except these are for plane 3 memory. 

Bits 6, 7,14, and 15 are reserved. 

3.4.6 (CMP) COLOR MAP 

The color map register allows for programming of the color map when the BMV is in "mapped" mode (via the 
CSR register). A mono output always contains the sum of all the intensity levels. Write only. 

Bits 0-1 indicate the blue intensity. 

Bits 2-4 indicate the green intensity. 

Bits 5-7 indicate the red intensity. 

Bits 8,9, and 10 indicate the plane 1, 2, and 3 addresses, respectively. 

Bits 11 -15 are reserved. 
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3.4.7 (SCL) SCROLL REGISTER 

The scroll register controls the addressing of the video memory planes for all operations. This register’s 
contents are always added to the Y coordinate addresses when writing and reading to the bit map. Changing 
the contents causes a vertical scroll on the screen (increment scrolls up; decrement scrolls down). 

Operations with the scroll register can be absolute. However, the scroll register may have any value when a 
program begins. Therefore, the register contents must be incremented/decremented or added to /subtracted from. 
After writing to the screen, the data is moved up or down by changing the scroll register contents. Read/write. 

Bits 0-7 indicate the scroll address offset. 

Bits 8-15 are reserved. 

3.4.8 (X) X COORDINATE 

The X register holds the horizontal scan location of all transfers to the BMV planes. It can be modified at any 
time during an operation with no effect on the operation. Read/write. 

In 1024 resolution, you will typically use X values of zero through 1023. 

Bits 0-9 indicate the X coordinate. 

Bits 10 - 15 are reserved. 

3.4.9 (Y) Y COORDINATE 

The Y register holds the starting screen location of all video operations defined in the PIC or OPC registers to 
the BMV planes. It can be modified at any time during the operation with no effect on the operation. 
Read/write. 

The typical values for Y will be zero through 239. 

Bits 0-7 indicate the Y coordinate. 

Bits 8-15 are reserved. 

3.4.10 (CNT) COUNTER 

When the counter register is loaded with anything but a zero, a transfer is started. The counter decrements 
after each cycle (bit or word) until the counter is zero. When zero, the counter is stopped and the transfer done 
bit (CSR bit 15) is set. The counter can only be loaded if the transfer done bit is set. Loading the CNT register 
clears the done bit. Write only. 

Bits 0-15 are available for use (hence the count may be from 0 to 65535 cycles). 

3.4.11 (PAT) PATTERN 

During a transfer, the least significant bit of this register can be used as data during an update modification 
cycle for each plane. After each cycle in bit mode (see CSR bits 8 and 9), the pattern register contents are 
rotated right one bit (for example, bit 0 shifts to 15,1 to 0,2 to 1, etc.). The pattern register can only be loaded if 
the done bit (CSR bit 15) is set (the CNT register is zero). Write only. 

Bits 0-15 are available for indicating the pattern. 

The pattern is indicated with ones (draw pixel) and zeros (don’t draw pixel). For example, 101010b (52o) could 
be used to draw a dotted line. 
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3.4.12 (MBR) MEMORY BASE 

This register assigns the starting address of the 32kb BMV memories page that the bit map video controller 
responds to. The starting addresses, as they appear on the CTI bus (I/O page/CTPAGE), are on any 32kb 
boundary. The register contents are then compared to the CTI bus DAL lines (bits 15 - 21) respectively. Write 
only. 

Bits 0-6 indicates the memory base address. 

Bits 7-15 are reserved. 


WARNING 

Altering the memory base value may crash the system. I do 
not know what values are safe to use with this register, 
hence the demostration programs do not write to this 
register. Since MBR is write-only, there is no way of 
determining what value is in there to begin with. 


PLAYBMV PROGRAM - PLAY WITH THE BITMAP REGISTERS 

4.1 Introduction 

This sample program allows you to manipulate the BMV registers. 

After running the program, the IDSLOT subroutine is used to find the BMV card slot. MAPCT is then used to 
map to the CTPAGE region with the slot number and APR specified. 

PLAYBMV uses the GETREG subroutine to read the values of the readable registers. PUTREG is used to place 
the user-specified values into the writable registers. 

The user specifies the registers and corresponding values. The values are not sent until the user indicates so. 

4.2 Entry Screen 

The entry screen lists the registers and their contents. 

You refer to a register by using its associated number in the # column. 

There are two Got and Put columns; DEC lists values in positive integer format and OCT lists values in octal. 

The Got columns list the values found in the readable registers after performing a "send values" command. (The 
registers are read once during start-up.) The Put columns list the values that you have entered (or those 
assigned after a clear/reset command); these values are placed in the BMV registers via the "send values" 
command. 

Registers marked with an asterisk (*) mean that the associated Put values will NOT be placed into the 
corresponding registers when you issue a "send values" command, even if you place new values into the Put 
columns. This is done either because the register is read-only (BMIDR), is ignored by the system (BMRES), or 
the effects are unknown (BMMBR). As mentioned in section 3.4.12, altering this value may crash the system. 

Note 

If you later wish to have PLAYBMV place the MBR value into 
the register, you may edit the PUTREG.MAC file and uncomment 
the MBR's MOV line. 

Decimal values are the default mode of entry. To change a register's value, type the register number, a comma, 
then the value. To send all values in the Put column to the registers, enter a 0,0 (zero, comma, zero). To quit 
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PLAYBMV, enter 0,1 • To clear the screen and reset the Put column values, enter 0,2. To toggle between entering 
register values in decimal or octal, enter 0,3; the first value (register #) will ALWAYS be decimal. 

Decimal register values may be positive or negative. A negative value is made positive by adding it to 65536. 
Decimal values may be no more than 6 places (including minus sign). Octal values may be no greater than 
177777. 

Note that some register values may be larger than what this program allows; this limitation is just for fitting 
the values in columns on the screen. 

4.3 Sample Entries 

When you run PLAYBMV, you will press RESUME to reach the entry screen. Both your commands and the 
BMV’s drawings will appear on this same screen. 

Besides scrolling and color changing, the only other visible actions performed by the BMV is line or dot 
drawing. If you want to draw a box — filled or otherwise — you must draw all four sides and optionally fill it 
(with more lines) yourself. There are no box commands as in CORE graphics; there are no fill commands as in 
GIDIS. If you want to draw a circle, you must use your own trig functions and draw each dot of the circle 
yourself. The same holds true for text or fonts: You must set each pixel yourself. 

Therefore, you probably want to limit your BMV usage to only those aspects that are speed critical, and these 
are usually related to dot, line, or curve drawing. For extra things like text or colorful borders, you can still use 
CORE or GIDIS. Be aware, however, that by changing the BMV registers yourself, and subsequently using 
CORE or GIDIS, you can cause some strange things to happen. Again, this sort of thing is a matter or trial and 
error. You are never just limited to using the BMV when you take control of the registers; but, you must be aware 
that conflicts can occur if you pass the reigns. 

4.3.1 DRAWING LINES 

Enter the following pairs of values, pressing RETURN after each. A comment is listed after each: DO NOT 
ENTER THE COMMENTS. 

If an error message appears, try entering the line again. If you make a mistake, enter 0,2 to clear the screen. If 
you get into real trouble, control-C out of the program and run it again, or turn off the computer for a moment. 

If OCTAL mode is already set (it is if the prompt asks you for an octal value instead of a decimal value), then 
do not enter the 0,3. 

0,3 

3,142300 
4,42 
5,21042 
7,0 

10,1000 
11,22222 
0,0 


(Toggle OCTAL mode) 
(Set control status) 

(Set plane 1) 

(Set planes 2 and 3) 

(Set no scroll) 

(Set counter 
(Set pattern) 

(Send values to register) 


The above instructions have the BMV draw a line about halfway across the screen (horizontally), underlining 
some of the column headers. The actual origin of the line may vary, because it depends what values are 
currently in the X and Y registers (and PLAYBMV's type and write statements are eventually resolved through 
the BMV, and hence they affect the X and Y registers, too). If you cannot see the line or the line gets erased, 
don't worry — you'll see how to position it in a moment. 

Note: PLAYBMV retains your entry values, so you only need change those registers you wish to modify -- you do 
not have to retype the entire list above unless you have issued a 0,1 or 0,2 command. 
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Note: Green cursor-sized "ghosts" may appear. These have to do with the Logical Operations set by the above 
procedures. If you do not want these ghosts to appear in your applications, you will have to turn off the cursor 
for the duration of the application, unless you reset the Logical Operations to compliment for each bitmap 
plane. 

3,142300 sets the control status register. This is done to "clean" it up, since the value may be anything at this 
time. This value allows for proper horizontal line drawing. 

4,42 sets plane 1. 42o is 1 00 010b. This action tells the BMV to move the pattern to the screen, and to set 1024 
horizontal resolution. (Remember that bits 6 through 15 are reserved, so you needn’t worry about trying to place 
values into those bits.) 

5,21042 sets plane 2 and 3. 21042o in binary is 001 00 010 001 00 010b. This sets plane 2 as follows: Move pattern 
to screen, 1024 horizontal resolution, and video memory enable. Plane 3 is set the same as plane 2. 

7,0 clears the scroll register. Scroll will be examined later. . 

10,1000 sets the counter to lOOOo or 512d. With a horizontal resolution of 1024d, this is half of the screen. The 
number you put in the counter is another trial and error matter, depending on how long a line you want. The 
number itself represents the number of pixels to be drawn (either on or off) beginning at the current X and Y 
positions, heading in the positive X direction a pixel at a time. If the line reaches the end of a screen line, it 
will be continued on the next screen line. Try it: Enter 10,100000 then 0,0. The line will extend over 32 screen 
lines (32768d/1024d = 32d, where lOOOOOo = 32768d). 

11,22222 indicates the pattern to be used for drawing the line. 22222o is 010010010010010b. The pattern can 
occupy 16 bits, but the number is too large to input into the current version of PLAYBMV. "1" tells the BMV to 
draw a pixel, "0" says to not draw a pixel. If you want a solid line, try entering 11,177777 and then 0,0. If you 
had made the line longer with the 10,100000 instruction above, then a solid strip of white will appear. To cut 
the line length back, reduce the counter value. 

To draw a dot, use a counter of 1. Be sure that the pattern's zero bit is a one, otherwise nothing will be drawn. 
For example, you can use: 

10.1 (Set counter to 1) 

11.1 (Set pattern to 1) 

To draw a dot. You may have to change the X and/or Y positions to see the dot, though. 

4.3.2 SETTING THE X,Y POSITION 

To set the origin of a line or dot, enter the new values in the appropriate registers. X is usually 0 through 
(horizontal resolution minus one), which for this example is 0 through 1023. Y is usually 0 through 239. If you 
use larger values, the BMV will "wrap" the position around the appropriate axis, just like it wraps lines with 
high counter values over several screen lines. 

To play with the X and Y positions, set the counter and pattern registers to draw a visible line. Then, do the 
following (in octal): 

8,0 (Set X register) 

9,256 (Set Y register) 

and enter 0,0 to send the values to the BMV. The line should now appear above the enter-value prompt line. 
Try different X and Y settings. When you change X or Y values, you do not have to alter any other registers; 
PLAYBMV will use the previous count and pattern you specified. 
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4.3.3 DRAWING VERTICALLY 

So far, all of the lines have been drawn in the horizontal direction. You may also have the BMV draw in the 
vertical direction. To do so, enter a counter value and pattern, and then in octal enter: 

3,142700 (Set drawing top to bottom) 

0,0 (Send values to registers) 

If you wish to reset CSR to draw horizontally, use: 

3,142300 (Set drawing left to right) 

The CSR values given above may differ from those returned by the system because the system manipulates the 
reserved bits. When you set the CSR register, you do not have to send back the same reserved bit settings, and in 
fact the above values set the reserved bits to zero. 

4.3.4 SETTING COLORS 

The BMCMP register allows you to set the 8 (numbered 0 through 7) color entries for the color map. Bits 0 
through 7 indicate the color value, bits 8 through 10 indicate the location; bits 11 through 15 are ignored 
(reserved). 

To change the background color to blue (map entry 0), type in the following: 

6,3 (Set entry 0 to blue) 

0,0 (Pass to registers) 

To change the background to green, try 6,20; for red, use 6,200. To change the background back to black, enter 6,0. 
To change the text to red, issue the following: 

6,700 (Set entry 1 to red) 

0,0 (Pass to registers) 

Notice that this only changes the "old" text; the text that is rewritten by PLAYBMV is still in white. To 
change the "old" text back to white, enter 6,777. Notice here that the "old" text is now whiter than the 
redrawn text. You will have to play with the values to determine what RGB settings are necessary for 
displaying a text-normal white. 

To change the redrawn (current) text to red, type: 

6,3700 (Set entry 7 to red) 

0,0 (Pass to registers) 

To change this text back to white, enter 6,3777. 

Note 

The operating system draws normal text onto whatever 
plane(s) are currently enabled. (The PLAYBMV ends up using 
different planes in the course of your entries above.) The 
combination of enabled planes is 8. And, since you can set 
each of these combinations to a different color, you can 
effectively have 7 (not counting background/black) different 
colors of normal text on the screen at the same time! (Just 
enable the plane combination before drawing the text.) 

GIDIS and CORE graphics both use this method for drawing 
their graphics text. Now you can apply the same techniques 
to normal text. 
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(Note: You can force the text to appear on plane(s) of your choice in PLAYBMV by disabling the planes you 
wish, then by issuing a reset (0,2); the subsequent text display will then only be on the planes you specified.) 

To change the cursor "ghosts" from green to blue, enter: 

6,3003 (Set entry 6 to blue) 

0,0 (Pass to registers) 

While it is unknown what causes the "ghosts" to appear, by entering 6,3000 you can at least make them 
disappear (this sets their color to black), or you can change their color if you require their presence to flag 
certain parts of your application's screen display. 

You will have to play with the other color entries to see what they affect. 

By default (at least in this demo), the BMV uses color map entry 7 for any lines you may draw. This is all well 
and good until you try to draw separate lines with different colors: Changing entry 7 will affect ALL lines 
previously drawn. 

To draw differently colored lines, you must set the plane combination before you draw the line. The color of the 
plane combination (there are 8 combinations, and hence 8 color map entries -- one for each combination) also 
needs to be set in advance of the draw if you wish the line to appear in the desired color. Color map entry 
values may be changed at any time; changing an entry value immediately changes all pixels drawn with that 
entry. 

Note: You do not have to set the pattern, count, X, or Y registers to set the color map; in other words, you do not 
have to draw something to use this register. 

4.3.5 SCROLLING 

Before trying to scroll, you should reissue the commands given in section 4.3.1 above. This is to ensure that all of 
the planes will be used in the scrolling process. 

The BMV adds the value you place into the scroll register and uses the sum to scroll the screen by the indicated 
number of screen lines (a screen line being a pixel thick). Unlike a text scroll, as performed with escape 
sequences, a bitmap scroll wraps the entire screen; in other words, an upward scroll would cause the lines at the 
top of the screen to appear at the bottom, and everything else would be moved up accordingly. 

You must change the contents of the scroll register every time you wish the screen to scroll, as the BMV performs 
scrolls in relation to the offset of the last value. Hence, putting the same value into the scroll register twice in a 
row will not do anything. 

For an example, enter the following commands: 

7,10 (Set scroll value) 

0,0 (Send values to registers) 

The entire screen will be scrolled upward. To scroll upwards again, try entering 7,20. A 7,5 will scroll the screen 
down. You can test large and small values to see how far the screen will scroll. To reset the screen, you must 
clear it, as with the 0,2 command. 

4.3.6 CHANGING THE HORIZONTAL RESOLUTION 

So far in the above demonstrations, the horizontal resolution has been left at the default 1024. To use a 
different resolution, you must first disable color mapping (CSR bit 10) and then specify the resolution in 
registers PIC and OPC. 

To set the horizontal resolution to 512, enter the following commands. (You may wish to clear the screen with 
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0,2 and then reenter the section 4.3.1 commands to properly enable the planes.) 

3,140300 (Disable the color map) 

4,52 (Set plane 1 to 512 res.) 

5,25052 (Set planes 2 and 3 to 512) 

0,0 (Send values to registers) 

After entering the 0,0 the text on the screen should appear flaky, and some of the colors should have changed. 
Also, any lines that might be drawn should have half the horizontal resolution. To reset the resolution to 1024, 
enter the following: 

3,142300 

4,42 

5,21042 

0,0 

The text should appear normal again, and the colors should be reset as the color map "kicks in." 

To set the screen to 256 resolution, enter the following: 

3,140300 (Disable the color map) 

4,62 (Set plane 1 to 512 res.) 

5,31062 (Set planes 2 and 3 to 512) 

0,0 (Send values to registers) 

Section 2.2 mentions that more colors are available in reduced resolutions. This is possible because the adjacent 
pixels are not used for display, they are used for determining the color. (In 1024 mode, all pixels are used for 
display and the color map determines the colors.) 

To see this affect, first enable all planes and set them to the same resolution (512 or 256). Then, enabling one 
plane at a time, draw a line; use a different pattern for each plane. The resulting overlaid lines should be in 
several colors. 


REFERENCES 

If you wish to take advantage of all of the bitmap's capabilities, you must purchase at least the Professional 
300 Series Technical Manual listed below. If contains brief descriptions of all of the bitmap registers and their 
appropriate bit settings. 

The other references aided in mapping to the CTPAGE region or in providing some helpful explanations. 

1. Programming RSX-11M in Fortran - Contains FORTRAN and MACRO mapping examples. Three volumes. 
Order numbers EY-0061E-SG-0101, EY-0061E-SG-0201, and EY-0061e-TP-0001. 

2. Professional 300 Series Technical Manual - Detailed bitmap register information. (No programming 
examples, though.) Two volumes. Order numbers EK-PC300-V1-001 and EK-PC300-V2-001. 

3. The ("Shelf-Cracker") Professional Toolkit ringbinder series - You’ll at least need the P/OS System 
Reference Manual for the list of mapping functions. About eight volumes. Order number QBA14-A3. 

4. PDP11 Processor Handbook - Explains how the APRs are used by a task, and how they're used in mapping. 


FURTHER NOTES 

If you wish to use GIDIS or CORE Graphics and then manipulate the BMV registers, be sure to initialize GIDIS 
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or CORE once at the beginning of the application. Be aware that you may crash GIDIS or CORE if you alter a 
register whose value they are counting on to be under their control. 

If you are multitasking, you should only allow one task to be in control of the BMV registers at one time. You 
may lock up the system if several tasks try to do things to the BMV at the same time. 

You do not always have to change all BMV register values at once. Some actions only require changes to one 
register. Therefore, you can create separate subroutines for loading various registers and leaving others alone. 

OCTAL is easier to use in figuring out what values to place into what bits than DECIMAL. Each OCTAL digit 
can represent three binary digits, as illustrated below. 


OCT 

BIN 

Dissection 

1 

001 


12 

001 010 

876 543 210 -bits 

123 

001010 011 ~> 

001 010 011 -BINARY values 

1234 

001 010 011100 

V V \/ -groups of3 

1777 

001 111 111 111 

12 3 -OCTAL 

7777 

111 111 111 111 



Pad bits with zero if you need to complete a group of three. 

The monochrome/color setting on the P/OS Setups Menu affects the performance of certain Extended Bitmap 
Options card functions. Generally, a monochrome setting will inhibit the use of certain color/plane modes, even 
if you have a color monitor attached you your system. 

However, do not specify a color setting if you do not have a color monitor, or you may cause your monochrome 
monitor to be overdriven and subsequently damaged. 


ABBREVIATIONS 


APR 

Active page register (section 1.3) 

b 

Indicates preceding value is binary (ex: 101b) 

BITMAP 

BITMAP region (section 2.1) 

BMV 

Bitmap video (section 2.1) 

cn 

Computer Terminal Interconnect (section 3.2) 

CIPAGE 

CTPAGE resident common (section 3.2) 

d 

Indicates preceding value is decimal (ex: 82d) 

EBO 

Extended bitmap option card (section 1.5) 

GEN 

GEN partition (section 3,2) 

kb 

Kilobytes (ex: 2kb = 2 x 1024 = 2048d bytes) 

0 

Indicates preceding value is octal (ex: 1776o) 

PRO 

Professional series computers (300 through 380) 

TFWBMP 

TFWBMP region (section 2.1) 

VCR 

Video control registers (section 3.3) 


Contents of Graphics Demo Disks 

Diskette 1 - BITMAP DEMO DISKETTE 

These programs were compiled and linked on P/OS V2.0 on a PRO/350. The programs were test-run on P/OS 2.0 
and 3.0 on PRO/350s. 

SLOTTEST - Finds the bitmap card in any slot. 
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AUTOCT - Maps to bitmap through the CTPAGE and displays register contents. 

RUNTCT - Maps to bitmap through the CTPAGE and displays register contents. 

PLAYBMV - Maps to bitmap through the CTPAGE and displays register contents. Allows user to change 
contents. 

Diskette 2 - BITMAP DEMO SOURCE CODE 

This diskette contains the source code to the four applications. 

[SLOTTEST] - Finds the bitmap card in any slot. 

[AUTOCT] - Maps to bitmap through the CTPAGE and displays register contents. 

[RUNTCT] - Maps to bitmap through the CTPAGE and displays register contents. 

[PLAYBMV] - Maps to bitmap through the CTPAGE and displays register contents. Allows user to change 
contents. 

Diskette 3 - Draw Cardioid Patterns in Color 

This program accesses the bitmap to draw varying color patterns. 

This is a public domain program, written by someone in DEC. The only ’’documentation” that came with this is 
that provided in the source code. 

Diskette 4 - Screen Save and Redraw Demos 

[BWDEMO] - This directory contains a demonstration program for the BWBMP text-only bitmap (screen) 
saving/restoring program. PASCAL source code is provided. 

[COLDEMO] - This directory contains a demonstration program for the COLBMP graphics-and-text bitmap 
(screen) saving/restoring program.PASCAL source code is provided. 

[BWBMP] - This directory contains the MACRO-11 source code for the BWBMP task. 

[COLBMP] - This directory contains the MACRO-11 source code for the COLBMP task. 


Editor's note: This collection has been added to the PRO Public Domain colection as MISC-5. It also includes a 
fifth diskette that contains this article. See the next article for more details. 


Catalog Updates to the PRO Public Domain Software Collection 

By Gary Rice, PC SIG Newsletter Editor 

Since last month, the following software has been added to the collection and/or added to the catalog. Please 
note that the "descriptions" are just extracts from the "README.1ST" file that generally accompanies each 
software offering on the SIG tape or other source. 

The "catalog" has grown to a size now that I have put it on it’s own diskette. As I publish updates, they are 
also entered into the "catalog" at the same time. Therefore, if you want an "up-to-the-minute" listing of the 
PD collection, simply send a diskette and ask for "CATALOG". 


Catalog # Description 

CATALOG The current diskette based PD collection 
1 diskette 


PC-23 



F81-7 Version 23 of RSX RATFOR 


2 diskettes; Sources included; NO objects; NO task images 
RATFOR, FORTRAN-77, MACRO 


F81-8 Ratfiv Version 2 

Ratfiv is a structured Fortran preprocessor providing SWITCH, IF - ELSE, WHILE, FOR, DO, 
REPEAT - UNTIL, STRING, and BREAK and NEXT constructs. Also supported are INCLUDE files, 
DEFINE for symbolic constants and macros with arguments, conditional compilation, formats in read, 
write, encode, and decode statements, use of >, <, etc. instead of .GT., .LT., etc, and the RETURN 
VALUE construct in functions. 

2 diskettes; Sources included; NO objects; NO task images 
RATFOR, FORTRAN-77, MACRO 


F81-9 BOGGLE: This program plays "Big Boggle", a game in which the players try to form words of 3 or 
more letters from an 5x5 array of letter cubes using contiguous cubes. This game acts as an opponent. Use 
a real Big Boggle board, run the program and enter in the letters as requested. The program will write 
out the words it finds on the terminal and to a file BOGGLE.OUT. Sorry, it doesn’t support the "Qu" 
cube. No need to install the task, put BOGGLE.DIC in your UIC. 

SORT: This is a major rewrite of the "sortc" program on the DECUS C kit. It’s a lot faster, and needs 
essentially no stack, and a temp file only slightly larger than the input file. Runs as task "...SOR" 
SUPERDUMP: A "full bore" file/device dump utility. Documentation and source in SOD.RNO and 
SOD.C. Does everything you’ll ever want, including file header dumps, with multi-header support. 
Runs as task "...DUM". 

CHAT: This program allows users to chat with each other from terminal to terminal. Install, runs as 
"...CHA". Uses IO.WBT’s so you get auto A R while typing. Looks a bit kludgy, but it's convenient and 
prevents full-duplex garbage when both parties type at once. If the called party’s terminal is 
attached, it announces "Request to chat" and waits for the terminal to become available. The caller 
sees "CHAT" when he has attached the other terminal. The caller types A Z to terminate chatting. 
TODAY: Writes out date and time in English, per the format used by Robert J. Lurtsema, a classical 
radio announcer in the Boston area. Also says the phase of the moon. Written by Martin Minow. Runs 
as task "...TOD". 

HANOI: Does the "Tower of Hanoi" on a VT-52 or a '100 in ‘52 mode, actually moving the rings 
visually between posts. The first time I ran it I cracked up. Install it with /TASK=...HAN and say 
HANOI n, where "n" is the number of rings. Try 4 the first time. I think Dave Conroy wrote it, and 
Martin Minow hacked on it. 

JARGON: This file is a riot! It contains a valuable dictionary of computerese, straight from the 
Stanford/MIT Artificial Intelligentia. I got a big kick out of reading it, and keep my listing close by 
at all times for ready reference. 

1 diskette; SOME sources; NO objects; SOME task images 
C 


S84-1 Michael Reese BASIC - original version This version of BASIC runs on RSX, IAS, and VMS. 

3 diskettes; Sources included; SOME objects; SOME task images 
MACRO 


MISC-5 An Introductory Guide to the Professional 300 Video Bitmap 

The Professional 300 computer has proven to be an excellent graphics workstation. The use of GIDIS 
graphics is straight forward and easy to use, CORE graphics is only slighly more complex. However, 
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to take full advantage of the graphics capabilities of the PRO requires a knowledge of directly 
addressing the bitmap. The intent of this offering is to provide an introductory explanation of the 
workings of the PRO/300 screen bitmap. 

5 diskettes; Sources included; NO objects; Task images included 
FORTRAN-77, MACRO, Pascal 

Distribution of the Public Domain Library is handled in the following way: After looking through the 
"catalog" and selecting the items you want, send me enough diskettes to hold the software you desire. Diskette 
counts are listed with each catalog entry. Include a return mailer, box, carton, palette, etc. sufficiently large to 
hold the diskettes. Include enough postage to pay for the return trip. I will NOT use UPS. Sorry. 1st class mail 
is recommended, but parcel post is ok. I will then copy the requested software for you and send it along. Give me 
at least a week for ANYTHING (plus travel time). Large (more that 5 diskettes) orders will likely take longer. 
Specify the software you want by catalog number. 

PLEASE don’t ask for "specials". It took a lot of time to put THIS collection together. 

Contributions are also welcome. However, if the work is NOT YOURS TO GIVE, please DON'T. 

In addition to this diskette based distribution, we are planning a tape distribution as well. The tape will be 
available after the Spring '88 symposium in the following formats: RSX BRU (1/2 " 9 track 1600 BPI and TK50); 
VMS BACKUP (1/2" 9 track 1600 BPI and TK50). The tape will contain EVERYTHING that we can assemble 
by then. 

Send your diskette based contributions and/or software requests to me: 

Gary Rice 

PC SIG Newsletter Editor 
McDonnell Douglas 
5555 Garden Grove Blvd. 

Westminster, CA 92683 
Send your tape based contributions ONLY to: 

Tom Hintz 

PRO/MAC/WORKSTATIONS Working Group Chair 
University of Florida 
IFAS Computer Network 
Bldg 120 

Gainesville, FL 32611 

OR BRING THEM WITH YOU TO SPRING SYMPOSIUM IN CINCINATTI! 

If you are submitting something to the collection, please include a signed copy of the following statement with 
your submission: 

The program that I am submitting to the Public Domain titled _ 

does not contain technical data/information that is proprietary, classified under US Government Secrecy 
Laws, controlled by non-disclosure agreements with the US Government or third parties or governed by US 
Department of State's International Traffic in Arms Regulations (ITAR). 

Full and irrevocable permission and consent is hereby given to DECUS to reproduce, distribute and publish in 
whole or in part, in any form and without restriction, this program or revision and any information relating 
thereto. The undersigned hereby warrants and represents that s/he has good and sufficient right, interest and 
title in and to this program or revision and the related information to grant such permission to DECUS. 
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PRO Software List Update 

Coordinated by Gary Rice, PC SIG Newsletter Editor 

In an effort to keep you informed about software being shipped from various vendors, I began the following list 
in April, 1986. This list was last published in the April, 1988 issue of these Newsletters. The updated list 
reflects information that I have received as of March 19, 1988. An asterisk by an entry indicates that the item 
has changed or been added sine the last time the list was published. 



List 

Last 

Source 

Still 

P/OS v3 

DEC Software 

Price 

Rev 

of info 

Avail? 

Supported? 

20/20 

495 

1.0.54 

User 

Yes 

UNK 

Athena/Graph 

450 

1.0 

DEC 

Yes 

UNK 

BASIC-11 /RT-11 (Replaced - See BASIC-PLUS/RT-11) 




BASIC-PLUS/RT-11 

UNK 

3.0 

DEC 

Yes 

N/A 

CT*OS 

UNK 

1.0 

DEC 

Yes 

UNK 

Design Graphix/Executive 

595 

1.0 

User 

Yes 

Yes 

Easyentry 

995 

3.0B 

DEC 

Yes 

UNK 

FORTRAN IV/RT-11 

495 

2.8 

DEC 

Yes 

N/A 

Installation & Maintenance 

UNK 

3.2 

DEC 

Yes 

Yes 

LOGO 

350 

1.4 

DEC 

Yes 

UNK 

MAIL-PLUS 

N/A 

1.0 

DEC 

No 

N/A 

MJA Accounts Payable 

600 

5.2 

DEC 

Yes 

UNK 

MJA Accounts Receivable 

600 

5.2 

DEC 

Yes 

UNK 

MJA General Ledger 

600 

5.2 

DEC 

Yes 

UNK 

MJA Order Entry/Inventory 

600 

5.2 

DEC 

Yes 

UNK 

MJA Payroll & Personnel 

600 

5.2 

DEC 

Yes 

UNK 

NPL Information Management 

N/A 

1.4 

DEC 

No 

UNK 

Phoenix-PRO 

1795 

1.0 A 

DEC 

Yes 

UNK 

P/OS ADCCP Driver 

UNK 

1.0 

DEC 

UNK 

UNK 

P/OS (Diskette) 

N/A 

1.8 

DEC 

No 

No 

P/OS (Hard Disk) 

475 

3.2 

User 

Yes 

Yes 

P/OS Hard Disk (Arabic) 

783 

R3.1 

DEC 

Yes 

Yes 

PRO 2780/3780 

53 

1.2 

DEC 

DECUS 

No 

PRO Application Starter Kit 

399 

1.0 

DEC 

Yes 

No 

PRO/Associate 

N/A 

1.0 

DEC 

No 

No 

PRO/BASIC 

195 

1.4 

DEC 

Yes 

Yes 

PRO/Comm (diskette) 

N/A 

1.8 

DEC 

No 

No 

PRO/Comm (hard disk) 

195 

3.0 

DEC 

Yes 

Yes 

PRO/CPM-80 

UNK 

1.1 

DEC 

UNK 

UNK 

PRO/ Datatrieve 

495 

2.0 

User 

Yes 

Yes 

PRO/DECnet 

250 

2.1 

DEC 

Yes 

Yes 

PRO/FORTRAN-77 Debug (See PRO/Toolkit Symbolic Debugger) 



PRO/IVIS 

UNK 

3.1 

DEC 

Yes 

Yes 

PRO/Laboratory Subroutine Lib. 

300 

1.2 

DEC 

Yes 

Yes 

PRO/NAPLPS 

N/A 

1.0 

DEC 

No 

No 

PRO/Office Workstation 

UNK 

2.0 

DEC 

Yes 

Yes 

PRO/PRODUCER Toolkit 

300 

1.6 

DEC 

Yes 

Yes 

PRO/RDT 

495 

1.1 

DEC 

Yes 

Yes 

PRO/Scientific Subroutine Library 

300 

1.3 

DEC 

UNK 

No 

PRO/SIGHT 

295 

1.1 

User 

Yes 

Yes 

PRO/SNA 

N/A 

1.1 

DEC 

No 

No 

PRO/Smart Mailer 

53 

1.0 

User 

DECUS 

Yes 

PRO/Toolkit 

520 

3.2 

DEC 

Yes 

Yes 

PRO/Toolkit BASIC-PLUS-2 

495 

2.5 

DEC 

Yes 

Yes 
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List 

Last 

Source 

Still 

P/OS v3 

DEC Software 

Price 

Rev 

Qf infp 

Avail? 

Supported;. 

PRO/Toolkit COBOL-81 

495 

2.4 

DEC 

Yes 

Yes 

PRO/Toolkit DIBOL 

495 

1.7 

DEC 

Yes 

Yes 

PRO/Toolkit FORTRAN-77 

495 

5 2 

DEC 

Yes 

Yes 

PRO/Toolkit PASCAL 

495 

13 

User 

Yes 

Yes 

PRO/Toolkit Real Time Library 

150 

2.1 

DEC 

Yes 

Yes 

PRO/Toolkit Symbolic Debug 

200 

2.0 

DEC 

Yes 

Yes 

PRO/VENIX 

495 

2.0 

DEC 

Yes 

N/A 

PRO/Videotex 

895 

1.0 

DEC 

Yes 

UNK 

Professional CTS-300 

995 

1.0 

DEC 

Yes 

N/A 

Professional Real Time Lib/RT-11 

250 

1.0 

DEC 

Yes 

N/A 

PROSE PLUS 

295 

2.0 

User 

Yes 

Yes 

RS/1 

1900 

12.0 

User 

Yes 

UNK 

RSX Host Toolkit 

UNK 

3.0 

DEC 

Yes 

Yes 

RT-11 

550 

5.4B 

DEC 

Yes 

N/A 

Supercomp-20 

N/A 

1.28 

User 

No 

UNK 

Synergy 

695 

2.0 

User 

Yes 

Yes 

VAX Host Toolkit 

UNK 

3.0 

DEC 

Yes 

Yes 

WPS/Plus 

695 

1.0 

DEC 

Yes 

Yes 


3rd Party Software 
(Vendor) 

List 

Price 

Rev 

Info 

Source 

Still 

Avail? 

P/OS 

221- 

D-M-DRIVER for P/OS 
(PROTO SYSTEMS) 

*195 

*V2/V3c 

Vendor 

Yes 

Yes 

Fingraph 

(Graphic M*I*S) 

N/A 

2.0 

DEC 

No 

UNK 

IT*OS 

(Intermation) 

UNK 

5.2 

User 

Yes 

UNK 

Online Disk Unfragmentor 
(By Hand) 

59 

2.0 

Vendor 

Yes 

Yes 

PRO/Menu Manager 
(Wasatech Computer) 

25 

1.0 

User 

*No 

No 

PRO/Sentinel 
(By Hand) 

47 

1.0 

Vendor 

Yes 

Yes 

PRO/Session Logger 
(By Hand) 

29 

2.0 

Vendor 

Yes 

Yes 

PRO/Text Locator 
(By Hand) 

43 

1.1 

Vendor 

Yes 

Yes 

RDM Relational Data Manager 
(Interactive Technology) 

995 

*4.1C 

User 

Yes 

Yes 

SATURN-BASE 

(SATURN SYSTEMS) 

750 

1.4 

Vendor 

Yes 

Yes 

SATURN-CALC 
(SATURN SYSTEMS) 

500 

3.0 

Vendor 

Yes 

Yes 

SATURN-GRAPH 
(SATURN SYSTEMS) 

500 

2.0 

Vendor 

Yes 

Yes 

SATURN-WP 

(SATURN SYSTEMS) 

600 

*5.0 

Vendor 

Yes 

Yes 

SPSS/Pro 
(SPSS Inc.) 

UNK 

1.1 

Vendor 

Yes 

Yes 

TKISolver 

(Software Arts) 

N/A 

1 (2A) 

User 

No 

UNK 


If you have received a shipment of software in the last month (and you DIDN'T get it in a fire sale), please 
compare the documented REV level to the one I have listed. If your software is more recent (or it isn’t listed at 
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all), please let me know so I can update the list. Also, if the source of my information is listed as "DEC", I 
would appreciate hearing from a user, since I've found that hearing about it from DEC doesn't always mean 
that it is actually shipping. I will publish a new list each time it changes. 

You can contact me at: McDonnell Douglas 

5555 Garden Grove Blvd. 

MS: K20 77/200 
Westminster, CA 92683 
(714) 952-6582 


Workstations Section 


Are We Crazy? Come to Cincinnati and Find Out! 

By Mark Sebern, Sebern Engineering Inc., P. O. Box 268, Cedarburg, Wl 53012 414/375- 
2200 

My New PC is a What? 

Many DECUS old timers shook their heads in Anaheim, upon seeing the PC SIG’s session entitled "My New PC 
is a VAXstation". After all, one asked, how could anyone possibly view a VAX, even a desktop VAXstation 
priced in four figures, as a personal computer? Everyone knows that VAXstations are for engineering 
departments of the Fortune 100, are bought in large quantities, and are dedicated to a single application. If you 
don't think so, just ask your local DEC sales rep. Oh, I forgot; she won’t talk to you because you do less than 
$500K a year with DEC. I guess you'll just have to take my word for it. 

Even so, there are a perverse band of users who insist on buying VAXstations and adopting them as their own 
"personal” computers. Maybe some see the VAXstation as the logical upgrade from the now "mature" 
Professional series. Perhaps others want to do PC style desktop publishing, but with a little more capability. 
Some may even have realized that DEC'S licensing price structure has made the VAXstation the obvious low 
end entry into the VAX family. Most have more than one job to do, but want the comfort of a PC with the power 
of a "real" computer. 

Still the skeptics persist. One Cincinnati session was almost rejected because some on the scheduling committee 
felt that "PC to VAXstation Migration" was not an appropriate topic for the PC SIG. In the face of this 
incredulity, even the true believers tend to be shaken. Are we helping to move the PC SIG into the future, or are 
we off on a tangent? 

What do you think? 

Your cards and letters are always welcome. The people who would like to hear from you include: 

Lynn Jarrett, PC SIG Chair 
San Diego Union-Tribune Pub. Co. 

350 Camino de la Reina 
San Diego, CA 92108 
(619) 293-1130 

Tom Hintz, Workstations/Macs/Pro Working Group Chair 
University of Florida IFAS Computer Network 
Bldg. 120 Gainesville, FL 32611 
(904) 392-5180 
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Gary Rice, Newsletter Editor 
McDonnell Douglas 
5555 Garden Grove Blvd. 

MS: K200 77/200 
Westminster, CA 92683 
(714) 952-6582 

A Symposium Preview 

If you’re coming to Cincinnati, you are welcome to join the discussion. Sessions of interest might include: 

My New PC is a VAXstation 
Tuesday 9:00A - 10:00A 
Clarion - Bronze P009 

Electronic Publishing Keynote 
Tuesday 10:00A -11:00A 
Clarion - Bronze P027 

A User’s View of Interleaf 
Tuesday U:00A-12:00N 
Clarion - Bronze P011 

Color Maps on Workstations 
Tuesday 4:00P- 4:30P 
West 242 P017 

PC SIG Business Meeting 
Wednesday 12:00N- 1:00P 
West 250 & 251 P003 

Workstations Working Group 
Thursday 9:00A - 10:00A 
Clarion - Bamboo A P033 

PC to VAXstation Migration 
Friday 10:00A- 11:00A 
Clarion - Ivory A & B P010 

PC SIG Wrap-Up 
Friday 11:30A- 1:00P 
Clarion - Ivory A & B P006 


It's Your Move! 

So, all of you out there in the silent minority, let the SIG know what you think. If "VAXstation as a PC" 
information is of interest to you, you better say so before the naysayers get the better of us. If you've got 
something to contribute, send it in! If you make it to Cincinnati, let's get together. But however you do it, we 
need your expert opinion. Are we the crazy ones? 
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A Communication Program for Your VAXstation? 

By Mark Sebern, Sebern Engineering Inc., P. O. Box 268, Cedarburg, Wl 53012 414/375- 
2200 

Introduction 

In setting up my VAXstation as a personal computer, one of the functions I have been reluctant to tackle is that 
of a communication program. After all, Pro/Communications running under Synergy on my Pro-350 has provided 
trouble-free service, and it was only recently that I installed a DHQ11 on my VAXstation II/GPX, a pre¬ 
requisite for full modem control. 

However, as I type up this article in one window on the VAXstation screen, while downloading a program from 
CompuServe in another window, I think I waited a little too long to get started. But I'm getting ahead of 
myself. 

The Environment 

The testing described here was done on a VAXstation II/GPX, running MicroVMS 4.7 and VWS 3.2. A "brand P" 
Hayes-compatible 2400 baud modem was used, connected to a DHQ11 (TXcn:) port. I set the port to MODEM, 
HOSTSYNC, TTSYNC, and ALTYPAHD. I'm not sure that all of these characteristics are necessary for all the 
programs tested, and some comm programs make changes on their own. 

Communication Programs Tested 

There may be more that I'm not aware of, but I tried out four communication programs that run under VMS. They 
are: 


SET HOST/DTE (comes with MicroVMS) 

Kermit-32 (in the DECUS library) 

HOST32 (from CompuServe's VAX Forum) 

VAXNET (from the DECUS library or CompuServe) 


SET HOST/DTE 

The VMS DCL command "SET HOST/DTE" provides a limited terminal emulator. It also claims to support 
auto-dialing with Digital modems, though I was not able to test that. The documentation (DCL Dictionary 
page DCL-456 and MicroVMS V4.7 Release Notes page 2-5) states that a template autodialer routine is 
provided in SYS$EXAMPLES:DTE_DF03.MAR; however, I could not find that file in the MicroVMS kit. I was 
finally able to get a copy from a full VMS site, but did not pursue it further. 

The main reason I stopped fooling with "SET HOST/DTE" was that it seemed to mess up my VT220 emulator 
window under VWS. Specifically, after invoking DTE and then exiting, I found that the DELETE (<X]) key 
acted like the RETURN key, and that the right and left cursor keys acted more like A R. Using the "reset 
terminal" option on the KB window menu did not clear the condition; it was necessary to delete the window and 
log in again. I did not pursue this further, since DTE's limited capabilities didn't seem worth the trouble. 
Kermit-32 

I used Kermit version 3.3.111 from the DECUS library. It is available on the VAX86D portion of the Fall 86 
VAX SIG Symposium Tape (V-SP-61) under directory [.VMSKERMIT], This collection is available on TK50. 

I ran into the usual problems, like forgetting to set the correct access protection on KERMIT.EXE and on the 
DHQ11 line (TXAn:), so that I could access it as a non-privileged user, but those were easy to fix from the 
SYSTEM account. 

I was disappointed that the VMS version of Kermit does not have the modem and autodial support provided 
by Kermit-11, but maybe that is only a matter of time. Kermit-32 seems to be set up mostly as a server, assuming 
that you are dialing INTO the VAX, not OUT FROM it. Because of this, it is necessary to type your own "AT 
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DT 555-1212" command to the modem to get it to dial the phone. 


Nevertheless, Kermit-32 did work reasonably well as a terminal emulator. I didn't make any careful 
measurements, but it seemed to run a little more slowly than Pro/Communications at 2400 baud. When I 
captured an ASCII file ("LOG SESSION filename"), the BANNER display on the VAXstation registered 
almost solid 100% CPU usage by Kermit. It's not nearly so bad during Kermit protocol transfers, perhaps 
partially because of the lower throughput of the protocol. 

HOST32 

HOST32 is available on the CompuServe VAX Forum ("GO VAXSIG"). The accompanying documentation 
states: "HOST32 is copyrighted (c) 1986 by Stuart R. Fuller, and is released for private use. It may not be sold, 
either alone or as part of a package.” 

HOST32 may be downloaded from CompuServe in a "hexified" form, and a VAX MACRO program is available 
to convert it to an executable image. I had a little trouble getting it to run, because I failed to set up the LOG_IO 
privilege, which is necessary for correct operation of HOST32. Note that the program still runs without this 
privilege, but several features do not work! 

HOST32 supports the CompuServe "B" protocol, which is very convenient for downloading from the various 
CompuServe forums (formerly called SIG’s). It also supports ASCII file transmission and capture, without an 
error correcting protocol. Like Kermit-32, it does not include autodial support. 

VAXNET 

VAXNET was written by Robin Miller of Northern Telecom. I got it from the VAX Forum on CompuServe, but I 
think the same package is available as VAX-137 from the DECUS Library, or as part of the VAX-LIB-4 
collection. 

VAXNET is a VERY comprehensive package. It supports multiple protocols, modems, modes of operation, etc. It 
includes a full HELP library, with about the same content as the included (.RNO) documentation. The 
documentation is mainly for reference and is very weak on examples. It takes a while to figure out how to set up 
all the parameters. On CompuServe, for instance, I wanted the equivalent of "7 data bits, ignore parity”, but 
"ignore" is not one of VAXNET's options. I worked around the problem by setting the local terminal (i.e., VT220 
window) to "NOEIGHTBIT", but it would be a lot more convenient if VAXNET would do it. If it can, I don't 
know how. 

VAXNET offers some features not present in the programs mentioned previously, notably autodial modem 
support for several different modem types. There is also a script feature which can automatically interact 
with the remote system. The questions normally asked by VAXNET's opening dialog can be answered in 
advance by defining DCL symbols; you can set up a command procedure to set parameters for the host you wish 
to dial and then invoke VAXNET automatically. 

VAXNET supports KERMIT and XMODEM protocols, in addition to one of its own. An EASYLINK interface is 
provided, though I did not test it. The ASCII capture feature creates a stream file which must then be 
reformatted by a utility which is included in the kit. 

I was able to get VAXNET hung up once, to the point that I had to delete the process to clear the problem, but 
overall it seems fairly reliable. When filling a screen, the output is rather jerky, but the interactive editing 
response is quite tolerable. 

Missing Features 

As near as I can tell, none of these programs offers the equivalent of "PRINTSCREEN" or "<ctrl> 
PRINTSCREEN" to a designated printer. The PRINTSCREEN function can be largely handled by the VWS 
"print portion of screen" option, if you have a printer than understands SIXEL graphics. It's true that all of 
these programs can capture the incoming data in a file, for later printing. Still, it's not as convenient as the 
"printer port" protocol supported by Pro/Communications or real terminals. 
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What about PFT/CFT/MFT? 

Many Pro-300 users are familiar with the old Professional File Transfer (PFT/CFT) protocol, which is also 
supported on RSX systems as MFT. On Micro-RSX, you can invoke MFT as a server using ’’COPY/REMOTE". I 
don’t know of any support for MFT on the VAXstation (as a ’’terminal”, not a ’’server”), though there are times 
when it would be handy. In the meantime, I use PFT/CFT on the Pro under Pro/Communications, and then copy 
the files across Ethernet to the VAXstation. 

Where Are the Radio Buttons? 

Absent among the programs mentioned here are any which truly exploit the VAXstation display. No 
Macintosh-style bells and whistles are in evidence, such as graphic ’’file transfer progress” reports or 
pushbutton protocol choices. I suppose we’ll have to wait for DECwindows (Real Soon Now?) before we see such 
goodies. 

Summary 

Maybe there are other communication programs for the VAXstation that I haven’t seen, but none of those tested 
here really measures up in all respects. Still, HOST32 is very handy for working with CompuServe, because of 
the built in ”B" protocol. VAXNET comes pretty close to meeting my expectations, though printer port 
emulation and an "ignore parity” option would be handy. Kermit-32 works well, but lacks the autodial features 
of Kermit-11. The only commercial product tested, DEC’S SET HOST/DTE, has little to recommend it, even 
with a DEC modem. 

All in all, these programs do offer enough capability to get me off the Pro-350 and onto the VAXstation for 
most of my terminal emulation and file transfer. Speaking of which, it looks like my file transfer in the other 
window has finished; time to get back to work .. . 


VAXmate Section 

DMI Announces 60 MEG Portable Tape System for the VAXmate and 
AT/XT Compatibles 

By Lynn Jarrett, PC SIG Chair 

DMI, INC. an innovator of enhancement products for Digital Equipment Corporation personal computers is now 
marketing their newest portable tape system for the VAXmate and AT/XT compatibles. 

The system, known as the DM 371, operates with both the DMI DM 300 and the DEC RCD Expansion Systems 
for the VAXmate, and the IBM AT/XT compatibles. 

The DM 371 utilizes a ruggedized 3 1/4" streaming cartridge tape drive with the newest high density/high 
speed DC-2000 mini data cartridge which provides data reliability 100 times greater than previous larger 
cartridge backup systems. 

The required cables, controllers, and easy-to-use proprietary software are supplied by DMI based upon the 
system configuration it is backing up. 

The system allows you to store unlimited amounts of data in increments of up to 60MB per cartridge. It is truly 
the most cost effective portable tape system in the marketplace today." 

Unattended operation, automatic time and date backup, and file-by-file backup and restore are just some of the 
main features which are the result of the easy-to-use software supplied with the unit. DEC installations that 
have VAXmates and AT/XT compatible will now be able to resource-share the DM 371 across many computers. 
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The DM 371 simply plugs into the back of the P.C., weighs less than 3 pounds, and simple disconnect allows the 
user to easily transport the sytem to another PC. In addition to backup application, the DM 371 is ideal for 
transferring files from PC to PC, and also for archival storage of data. 

DMI is headquartered in Irvine, Calif., and can be phoned at (714) 583-1800. 


Rainbow Section 


Intersecting Concepts Announces MEDIA MASTER 5.0 

By Lynn Jarrett, PC SIG Chair 

Intersecting Concepts of Thousand Oaks, Calif., has released Media Master 5.0, a disk-to-disk format 
conversion utility for the IBM PC and PS/2 family of computers. 

The utility permits an IBM PC, XT, AT, PS/2, or compatible to read, write and format over 200 CP/M, MS-DOS, 
and TurboDOS disks. With Media Master, users can share information between previously incompatible 
computers by breaking the disk format barriers associated with different operating systems. 

New features in version 5.0 include support for the IBM PS/2 family of computer using 1.44 megabyte and 720k 
floppy drives, the capability to customize the program through setup files, full color support, on- line context 
sensitive help, first letter menu selection, and a much easier installation procedure. 

In addition, the program supports a "power user” mode which allows one physical floppy drive to have two 
logical names, one for normal DOS disks, and one for any special disk format the user may choose. For example, 
the A: logical drive would be used for normal DOS transfer, and another logical drive letter, say F: would be 
used for Kaypro transfers to the same drive. 

Registered end users can obtain upgrades for a small fee until May 1,1988 and after that the upgrade price will 
be a little more. Because Media Master is included in the company’s Media Master Plus and Accelerate 8/16 
products, similar upgrade terms apply. 

The five year old company publishes Media Master for the DEC Rainbow, Osborne, Kaypro, Sanyo 555 and Z- 
100 computers. Display Master, an EGA/VGA screen enhancement program for the IBM PC, and Code Blue, an 
IBM PC emulator for the DEC Rainbow. For more information contact: Mark Graybill, Intersecting Concepts 
Inc., 80 Long Court, Suite 1A, Thousand Oaks, CA.; or call 800-422-8018 (in CA 805-373-3900). 
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To register for on-line submission to the Pageswapper dial: 

(617) 262-6830 

(in the United States) using a 1200 baud modem and log in with the username 
PAGESWAPPER. 

Articles for publication in the Pageswapper can be sent (US mail only—no 
“express” services please) to: 

Clyde T. Poole, Pageswapper Editor 
University of Texas at Austin 
Dept, of Computer Sciences 
Taylor Hall 2,124 
Austin, Texas 78712-1188 

Preference is given to material submitted as machine-readable text (best is 
Runoff source). 

Please do not submit program source, as that is better distributed on the VAX 
SIG tape. 

Please do not submit “slides” from DECUS Symposia presentations (or other 
meetings) as they are generally a very incomplete treatment for those readers of 
the Pageswapper who are not so fortunate as to be able to travel to Symposia. 
Please do write articles based on such slides to get the content across to a wider 
audience than is able to attend. 

Change of address, reports of non-receipt, and other circulation correspondence 
should be sent to: 

DECUS U.S. Chapter 
Attention: Publications Department 
249 Northboro Road (BP02) 

Marlborough, MA 01752 
USA 

Only if discrepancies of the mailing system are reported can they be analyzed 
and corrected. 
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Editor’s Workfile 

Larry Kilgallen 

NET*.DAT File Security 

Be sure to read topic 942 in the Input/Output section this month. It tells about 
an undesireable loosening of file protection some sites have been discovering 
after the upgrade to VMS V4.6 or VMS V4.7. 

Pageswapper Typography 

Well, we have finally made the plunge into the world of proportionally spaced 
fonts. The type size is chosen to make the average line easy to read, according 
to the guideline of 75 characters per line indicated by Leslie Lamport in one of 
his talks. The front end, however, is VAX Document VI.0, and it prevents a 
designer from getting at any monospaced font between 9 points and 16 points. 
Until that is resolved I have chosen the smaller size, making examples hard to 
read but ensuring they will fit on the page. 

Your submissions are still welcome in Runoff format, and I think I can also 
convert LaTeX. 


VMSnet Address Correction 

by Tom Allebrandi 

In Jamie Hanrahan’s VMSnet article in the February Pageswapper , my address 
was listed as the place to send TK50’s for the VMSnet release. As of March 1 
we are no longer at that address. The correct address is: 

Tom Allebrandi 

c/o Advanced Computer Consulting, Incorporated 
700 Harris Street, Suite 101 
Charlottesville, VA 22901 
(804) 977-4272 
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A Tale of IBM Field Service 

by Terence M. Kennedy 
St. Peter’s College 
Department of Computer Science 
2641 Kennedy Boulevard 
Jersey City, NJ 07306 

Originally submitted to DECUServe 

[This might enlighten one as to an appropriate route a company might take to 
correct a difficult service problem — remember, this is the “Evil Blue Empire” 
that we are discussing .. . ] 

About 3 years ago, an IBM 3138 (that’s a 370 Model 138 CPU) I also manage 
was having strange problems. This machine was built about 1972, by the way. 
It would report irrecoverable errors on a disk drive, but when the operating 
system asked for the error status, the control unit returned a response that there 
had never been an error. Needless to say, this had the operating system taking 
fits. We called our regular service guy (you always get the same guy). He 
came out and couldn’t find anything broken, although the system was obviously 
misbehaving “It passes the diagnostics .. . ”). So, he called in the next level 
of tech support. Same thing. Next level — this guy arrives in wom-out jeans 
and a flannel shirt — so much for the IBM image — this guy manages to 
isolate the problem to one area, but he’s stumped too. 

Now, I have 3 IBM guys standing around. On the edge of their conversation, 

I hear things like “should we get Him?”. The consensus was yes. The next 
morning, this really strange-looking person shows up at our door. He manages 
to wheeze out “I’m from IBM to fix your 138”. So, we take him downstairs 
to the other 3. He doesn’t even look at them — he just goes into the CPU 
and looks around. About 3 minutes later he shows the other 3 which wire to 
change. After he left, I asked who he was . . . 

The answer — he was the original design engineer for that part of the CPU! 
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LUG News 


No I’m not saying that this is a reasonable system for DEC to emulate, but it 
did get the system fixed. Yes, whole assemblies can be replaced by minimally- 
trained personnel, but they lack the in-depth knowledge to determine why 
something complicated isn’t working, and they also lack the authority to order 
a complete swap of the failing subsystem. Without one or the other, they (DEC 
Field Service) are doomed to repeat the problem they had at my site, and will 
continue to lose business. Tme, the majority of service calls are of the swap- 
a-board or change-the-fuse type, and DEC does fairly well with this. Beyond 
that, things go downhill ... 


LUG News 

Meeting topics for May - from respective LUG Newsletters 

St Louis Local User’s Group 

5:30 pm — social time 
6:00 pm — dinner 
7:00 pm — program 

May — Digital picnic and Open House (at the Digital branch office, not the 
Salad Bowl) 

MIVAXLUG 


Lawrence Institute of Technology 
Management Building, Room M336 
10-Mile Road 
Southfield, MI 

6:15 Open Steering Committee meeting 
7:00 Main Meeting 

May 10 EMC — Optical Disks 
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Fall 1987 VAX SIG Tape 

by Glenn C. Everhart 
25 Sleigh Ride Rd 
Glen Mills, PA 19342 

Here is a listing of the Fall 1987 symposium tape from the DECUS US 
Symposium held at Anaheim, California. Due to the large volume of 
submissions, three tapes at 1600BPI are required to hold them. The following 
is a brief summary of their contents. 

Table 1-1 Fall 1987 VAX SIG Symposium Tapes 

Directory Contents 

[VAX87C...] Directory tree and tape 

[.anljohno] DCL interface for automatic submission of single command batch jobs. General 

multi-threaded VMS exec server symbiont. DECnet $GETxxl server. Memory 
virtual disk driver much more efficient than PDDRIVER. From John Osudar, ANL 

[.arc] Print on HP Laserjet including forms. EVE Plus updates. EBCDIC <-> ASCII 

converters. From Steve MacNeil, Access Research 

[.bassett] Loan and investment programs. Golf handicap system. Idle process watchdog. 

Fortran based menu system. VT241 colors, auto-dialer, DCL menu, Talaris fonts, 
DTRFIND. News update. Reminder (update from VPW version). Show users in 
Cobol. from Fred Bassett, JG Boswell. 

[.battelle] ARGNUM - find number of arguments passed to a subroutine. User UIC change 

via custom sys service. Filename from FID. File locate based on size, uic, etc. 
Pascal environment files. Save/restore hashed password in UAF. Struct. Macro 
library. TPU show/set directory, add function, keys, encode/decode. From Mark 
Oakley, Battelle Institute. 

[.bzl] LSE templates for Runoff and LSE. Sample for outgoing connection to PSI. 

Erlang blocking formulas. Programs to measure real VAX CPU speed. From 
Bart Lederman, ITT World Communications. 

[.ci] Monthly close VMS accounting. Count records in file. DIALUPINI for dialup 

modem stat set. DROIDS game (moved to [games.ci]). ENPAGE - paginate 
documents for LN03 & set margins etc. FORCEX - force exit on images. Print 
reminders from REMINDER program. System status report (SYSTATUS) with lots 
of abilities. From Ken Richardson, Compassion International. 

[.clement] Update to Bonner Runoff (large superset of DSR). Spy, another continuous 

system status routine. From John Clement, Bonner Lab, Rice Univ. 

[.clib] Non-DEC C library and a few utilities using it. From Eric Levy, Bear Systems. 
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Table 1-1 (Cont.) Fall 1987 VAX SIG Symposium Tapes 


Directory 

[.costello] 

[.csdhbo] 

[■djm] 

[.dolgen] 

[.down] 

[.dtredit] 

[.dtrsig] 


[.ellis] 


[.eros] 


[.eveupds] 

[.flecsvms] 


Contents 

[VAX87C..J Directory tree and tape 

Update (minor; bug fix) to TPC, a tape -> disk -> tape format independent copy 
utility. From Dennis Costello, National Nanofab Facility. 

Filter repetitive broadcasts on consoles on cluster so each console gets 
messages from its own CPU only. System services library. From Jonathan 
Welch, HBO &Co. 

Elect. Telephone book; run AUTHorize in any directory. Define VT2xx keys, 
info re identifier. Tell what files will be purged. See who uses a command 
procedure. List of VMS documentation set. From D. J. Maus, Fermilab. 

Utilities to make conversion to DECalc V3.0 a little easier. Utilities to reorganize 
a disk. From Wimpy Hudson, Dollar General. 

DOWN - utility to move around directory tree more easily. From Michael 
Wheeler, Tenn. Tech. Univ. 

Utility to facilitate editing DTR fields where you don’t have FMS or TDMS, 
DTREDIT. From David Swan, Greenville, Nova Scotia, Canada. 

ACCOUNTING - convert VMS accounting to something DTR can handle. Also 
terminal measuring process. ALLIN1 - DTR definitions for A1 files. CORPHONE 
- corporate phone directory in DTR. FUNCTIONS - more DTR functions including 
spawn and string length. NEWSLETTERS - old Wombat Examiner issues. 
PLOTS - more DTR plots. RECALL - use SMG to add command line recall 
to DTR. SYSUAF definitions for DTR. RSX accounting with DTR. Method of 
processing INSTALL/LIST/FULL to see what are most used images, shared 
images, etc. From DTR SIG, Bart Lederman, Librarian. 

Numerous kernel mode programming examples from the master of the art, 

Bruce Ellis. Such items as show process/files, purge working set of a process, 
etc... much more, very powerful but potentially dangerous utilities. Titles 
include: ADDRESSJTRANSLATION, DEADPT, DEALO, DUMP_BLOCK_COUNTS, 
LOAD_BLOCK_COUNTER, UNLOAD_BLOCK_COUNTER,SHOW_PROC_FILES, 
GET_HIT, PFM, PFMFILWRT, PFM_FORMAT, SHOWBASE, SHOW_SHARE, 
WSBLASTER, FAULT, PERF. 

BATCHACC - set account of batch job to submitter process. CPU hogs monitor. 
LIMITER - limit the number of sessions per username. NOPE - list what files 
(+ sizes etc.) of files that would be deleted in a purge. PASS - disallow reuse 
of passwords. PCT - show % use of CPU. SYSTAT and MEMSTAT - info on 
system processes and memory use. From Tom Bodoh, USGS Earth Resources 
Observation Systems (EROS). 

Update to EVEPLUS, from Denny Thury. 

FLECS and ALECS structured preprocessors for Fortran and Macro. Now totally 
native mode. From Michael Oothoudt, Los Alamos Lab. 
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Table 1-1 (Cont.) Fall 1987 VAX SIG Symposium Tapes 

Directory Contents 

[VAX87C...] Directory tree and tape 


[.flowers] 


[.games] 

[•grc] 


[.grover] 

[.howe] 

[.jcslug] 


[.ketech] 

[.kka] 

[.latshaw] 


Delete zero length files. Show disk space. Move around directory tree and/or 
draw tree. EDT ini files and wildcard editing. Differences of file uppercased, 
compressed, and trimmed. Documents in beautified form for EVEPLSPLS 
(from 87B tape). LaTeX document style manual. Mail UAF maintenance tools. 
VT2xx key definition support. Backup control command procedures. From Harry 
Flowers, Custom Computer Applications. 

HACK game from Dean Grover and CRIB game from MNVAXLUG 

CALC2SMG - Emulates HP calculator. EDT super emulator for TPU. Directory 
from within EDT. MODOBJ - fixup object files for more general addressing. Time 
VAX instructions accurately. From Rich Harris, General Research Corp. 

Updated EDT-Plus extensions to EVEPLUS. SWING graphical and screen 
oriented directory management program. From Dean Grover, Hughes Aircraft. 

EVE extensions, from Herb Howe, Oak Ridge National Lab. 

SETUSER - change username to that of another user w/o login. MAILUTIL - 
let a user see if mail from him has been read. SPEEDLOGIN - fast symbol 
definitions at login. LAB I/O control system. Local print of file to VT102 terminal 
printer. Load foreign tapes. TELEMAIL - bulletin board mail built on VAXNET. 
WATCH - watch other processes. From William Baker, Ford Aerospace. 

Standard menu interface software (with FMS or without). SETUSER - “become” 
another user if privileged enough. From Richard Snyder, KeTech Corp. 

Foreign tape reader, VERY flexible. EVE extensions. VMS_SHAR VMS “shell 
archive” for packing files for mailing. From Kurt Andersen, JPL. 

EDTEM - very extended EDT emulator in TPU, many extensions. From Mike 
Latshaw, Pacific Power and Light. 
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Table 1-1 (Cont.) Fall 1987 VAX SIG Symposium Tapes 

Directory Contents 

[VAX87D...] Directory tree and tape 

[.coy] DM - directory manager. SD - set default program. WPS-PLUS emulator 

in TPU, plus extensions. Color setup for VT241. WPS-PLUS emulator for 
LSE. SHOWME - show all the system can find out about a terminal. MCL - 
multicolumn file lister. NOTES update utilities. Procedures to build text libraries 
(.TLB). From Dale Coy, Los Alamos National Lab. 

[.levine] BREAKOUT - Building blocks for extended accounting utilities. HELLO - 

Command file for VT terminals; cookie type. INDEX - powerful Fortran cross 
referencer, static analyzer, and flowcharter. JUICER - Online and offline disk 
compression and file defragmenting. MUTEX - find sources of MWAIT states. 
NETLIST - condensed SHOW NET listing. QUICFONT - font editor for Talaris 
printers. SNAPSHOT - system snapshot utility runs every 15 minutes. TAPE 
- read/write blocked card images in ASCII or EBCDIC to tape, record length 
132 or less. TQE - print timer queue elements. VAXPAINT - convert MACPaint 
document into Talaris bitmap for plotting on Talaris. From Michael Levine, Naval 
Weapons Center. 

[.rcaf87] AMIGA - editors (including uEmacs 3.9e), spell checkers, graphics and Postscript 

access routines, VT100 emulators, convert Amiga pictures to form printable on 
DEC printers, AnalytiCalc spreadsheet for Amiga. Sources generally present. 
AnalytiCalc spreadsheet update for VAX, RSX, IBMPC, and AmigaDos. Update 
to LISTRS multicolumn lister from Chris Doran. RIM5 DBMS updated documents, 
source. Desktop Calendar update. FINGER update, supports VMS 4.6, LAT 
identification, secure operation (security bugs squashed), many customizations. 
LZW - Lempel Ziv Welch compress/decompress utilities used. NETNEW - 
about 10,000 blocks of utilities from Internet, indexed; includes VI in TPU, 
controllers for several processes from a terminal, LEX & YACC inputs for Ada 
parsers, Bulletin, SWING, much more. SSP - Scientific Subroutine Package 
w/comments. TARRDR - TAR tape format read & write from VMS. VMSDS - 
VMS disassembler to convert .EXE files to (recognizable!) .MAR files. Submitted 
by Glenn Everhart, RCA. 

[.sewell] MWEB - WEB adapted to Modula 2. WEBMERGE - merge multiple change 

files. SCANTEX - strip out parts of a WEB file not changed. LaTeX slides for 
LT005 session on WEB structured documentation system. From Wayne Sewell, 
E-Systems. 
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Table 1-1 (Cont.) Fall 1987 VAX SIG Symposium Tapes 
Directory Contents 

[VAX87E...] Directory tree and tape 

[.lilug] TIMESUM - make plot of no. processes vs time. PUTGET - fast file I/O for 

Fortran. TRAIN.DAT - VT100 demo. From John Hasstedt and Pierre Hahn, 
SUNY Stonybrook. 

[.matuscak] WANG IIS WP document conversion to MASS-11. From Joseph Matuscak, 

Babcock and Wilcox. 


VAX-10 






PAGESWAPPER - May 1988 - Volume 9 Number 10 

Fall 1987 VAX SIG Tape 


Table 1-1 (Cont.) Fall 1987 VAX SIG Symposium Tapes 


Directory 


[.meadows] 


[.merrimack] 


[.mivaxlug] 


[.mnvax] 


[.nanny] 

[.nds] 

[.news_src] 

[.nstl] 

[.nswc] 


[.pageswapper] 


Contents 

[VAX87E...] Directory tree and tape 

FILE - Change RMS attributes or dates on any files without copy. INDEX - 
find files based on lots of criteria (size, length, date, fragmentation, etc.) FAST. 
STATUS - fancy SHOW USERS plus DECnet info. VERB - decompiler for DCL 
tables, converts them to CLD files. From Joe Meadows, Jr., Fred Hutchinson 
Cancer Research Center. 

BATCH - command proc to generate Batch jobs interactively. Directory sharing 
utilities. Checkmail - see if you have mail. INTRO - poke in a system w/o 
privileges. LATHACK - find where a LAT terminal is. PANDORA - super TPU 
editor. More. From Rand Hall, Merrimack College. 

PRIVILEGE - set/reset privileges in menu fashion. CALCULATOR - SMG based 
calculator. GETQUI - get queue info. SWING rewrite from DEC. More. From 
John Gordon, MIVAXLUG. 

Subroutine for standard keyboard input in Basic. Force user to change his 
password. Video Attribute Text Formatter. Extended EVE. Statistical program. 
Editing and Runoff control program. Program to let privileged user become 
almost invisible. From Mark Van Overbecke, Macalester College. 

Powerful system management aid/idle terminal killer/priority monitor, from Dan 
Zirin, ZAR Ltd. 

Fast spelling checker from Jack Harvey, NDS 

Un*x NEWS rewritten for VMS; the celebrated Geoff Huston NEWS program. 
Handles USENET newsgroups on a VMS VAX. From Geoff Huston, Australian 
National Univ. 

SETDEF - set default program. FRED - powerful editor, complete but written 
in TPU. FLEXISMB - rewrite of print symbiont, flags etc. settable. From Perry 
Wischow, NORDA. 

BATCH - “instant” one - liner BATCH commands. MAILUAF - maintain mail 
files and forwarding. REMINDER - appointment reminder/tickler. OTHERNODE 
- execute commands on another node in DECnet object. NSWC_Server - time 
based and DECnet daemon. Check_Sessions - tell user where he’s logged in, 
where else on the cluster they may be logged in too. From Al Zirkle, Naval 
Surface Weapons Center. 

Pageswapper issues since Spring 1987 symposium and compressed VAXNotes 
file. From Larry Kilgallen, Pageswapper editor. 
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Table 1-1 (Cent.) Fall 1987 VAX SIG Symposium Tapes 

Directory Contents 

[VAX87E...] Directory tree and tape 

[.perfmon] 

[.piccard] 

[.remprint] 


VMS Performance monitoring (response time, % idle, average users, I/O, memory, 
disk usage, etc.) utility. From S. Charles Spriggs, E.l. DuPont. 

EDT TPU enhancements. From Richard Piccard, Kalamazoo College. 

REMPRINT - print one or more files on a remote system device. From Marty 
Adkins, Westinghouse. 
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Table 1-1 (Cont.) Fall 1987 VAX SIG Symposium Tapes 

Directory Contents 

[VAX87E...] Directory tree and tape 


[.restore] 

[.rwk] 

[.rsxfinger] 

[.Schumann] 

[.sealug] 


[.smith] 

[.softquo] 

[.spencer] 

[.sysmon] 

[.tulug] 

[.t_nieland] 

[.uair] 

[.vfe] 


RESTORE - recover deleted files from Files-11 ODS-2 disks. From W. B. 
Langdon, CERL. 

DTR system management aids. Pascal environment files. Command procedures 
for system management. From Ronald Kaltenbaugh, SYSCON. 

FINGER utility for RSX which communicates with Columbia University FINGER 
over DECnet. Shows users, what they are doing, and acts as a remote name 
server. 

ARCHIVE - Procedures to archive disk directories to tape. INCREMENTALS 
- locate which tape contains a file. OPRESPOND - method to do 2 way 
communications with operator during a batch job. Poker game. TERMTYPE - 
set symbol for a terminal type. WPS - WPS Plus emulator under TPU. From 
Dar Schumann, Farm Credit. 

MACINTOSH - read MAC files on VAX; file transfer; MAC tech notes. 

DECNET - conversational DECnet object. Remote print and batch control. 
Remote command execution. SHARE_EXE - builder for shareable .EXE 
builder. XMODEM - XMODEM communications program with much faster CRC. 
MODEM7 - Dialout companion to XMODEM. From J. James Belonis II, Univ. of 
Washington. 

Remote print and form control over DECnet. Network time maintenance utility. 
From David Smith, USMC. 

Soft Quota disk management system, from Marty Adkins, Westinghouse. 

EDT enhancements (including WPS keypad style too). TECO emulator for EDT. 
LSE section file implementing EDT initializer extensions. From David Spencer, 
Foundation Health Plan. 

Multiple process monitor utility to watch paging and page trimming. From William 
Flatt, Intercompany Pool, Spokane, WA. 

Menu program in Cobol. Amortization program. Define logicals from a central 
file. Give text of VMS error numbers. EDT enhancements. Purge working set. 
LG02 control files. Reminders. Operations help libraries. Save/restore recall 
buffer. Text library menu. More. From Les Stockton, Williams Co’s. 

EDTPLUS - EDT emulator in TPU with many additions. SEND - broadcast short 
message to other user. SETDEF - IN foreign utility. WSLTEX - WordStar to 
LaTeX filter. From Ted Nieland, Systems Research Labs. 

BBS- FULL function BBS system for VAX (message, conferences, uploads, 
downloads). CB - CB simulator for VAX. ETAPE - read/write EBCDIC or 
nonstandard ASCII tapes. OPERMENU - menu driven operator system. WHO - 
cluster-wide who’s on the system. From Dale Miller, UALR 

Vax File Editor, binary/hex/ASCII, EBCDIC, etc. disk editor or file editor. From 
Ward Condit, Maricopa Community Colleges. 


VAX-13 






PAGESWAPPER - May 1988 - Volume 9 Number 10 
Password of the Month 


Table 1-1 (Cont.) 

Fall 1987 VAX SIG Symposium Tapes 

Directory 

Contents 

[VAX87E...] Directory tree and tape 

[,vt2xx] 

Program VT2xx function keys F6 to F20, from E. Denise Anderson, Cordis 
Pacing. 

[.watson] 

EVE and EVEPLUS extensions; merged from many earlier ones with additions by 
Al Watson. Includes Emacs-like DIRED, mail interface, interface to Denison Univ. 
Spell Checker. From Allan Watson, Watson Consult. 

[.wolfe] 

Extended EVE with simple spell checker. Print symbiont with user defined 
headers (on each page). Virtual block (fast) I/O in Fortran. Demos. Lines of 
code counter. From Tom Wolfe, JPL. 


Password of the Month 


The VMS Password Generator, in addition to providing a pseudo-random 
“pronouncable” password, also provides guidance (similar to that in a 
dictionary) as to how the password should be pronounced. Did you know, 
for instance, that: 

kiemtshlj 

is properly pronounced: 
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DECnet-VAX Tips 

Originally Published in March 1988 Longwords 
the Newsletter of DFWLUG 

Problems in mixed PHASE lll/PHASE IV Networks 
Description: 

Areas are supported with TOPS-10 V7.03 (Phase IV) over Ethernet. Phase 
II I nodes in a multiple-area network must not be in the routing path between 
Phase IV nodes and must not be linked to nodes outside their own area. These 
limitations are based on the following restrictions under which Phase ID nodes 
operate in a Phase IV network: 

• DECnet-VAX Phase HI nodes cannot assume a node address greater than 
255, and cannot directly address a node with a node address greater than 
255. They also cannot route through traffic for nodes with addresses greater 
than 255. (Note that this limit may vary for other DECnet Phase HI nodes, 
up to a maximum possible address of 1023.) 

• Phase HI nodes cannot recognize area numbers in node addresses. A Phase 
in node cannot assume an area address, directly address a node outside its 
own area, or route through traffic for nodes in other areas. 

• Phase HI nodes cannot be connected directly to an Ethernet. 

• Phase in nodes must use routing initialization passwords when they are 
initialized in a Phase IV network. 

For more information on Area Routing Configuration, reference Appendix A in 
the Guide to Networking or Appendix A of the VMS V4.4 Networking Manual. 

MicroVMS V4.4+ Static Async Takes Long Time To Establish Circuit 
Symptom: 

MicroVMS V4.4 Static Asynchronous DECNET takes a long time to establish 
link. This scenario will extent itself to micro VMS V4.6 if a site upgrades from 
earlier versions and does not correct the problem. 


VAX-15 



PAGESWAPPER - May 1988 - Volume 9 Number 10 

DECnet-VAX Tips 


Analysis: 

There are several problems with Static Asynchronous DECnet under micro VMS 
V4.4. One is that circuits come up as “on”, but it can take some time (about 15 
minutes) to establish a link to the remote node under certain conditions. After 
around 15 minutes, you then get the event 4.14 Node Reachability Change 
when it finally establishes the link to the remote node. The second problem is 
when two circuits are toggled (OFF/ON), the asynch circuit never gains control 
of DECNET circuit even when it’s circuit cost is lower. 

Example: (Expected Behavior) 

• With circuits QNA-0 (cost 5) and TT-0-2 (cost 10), we see both circuits 
come up as ON and the QNA circuit is the active DECNET link because 
of the lower cost. You can lower the cost of circuit TT-0-2 to 1, and it will 
become the DECNET circuit in use. 

• If both circuits come up in ON state with a lower cost on the QNA and you 
turn the QNA-0 state OFF, the TT-0-2 circuit will then become the active 
DECNET circuit. 

The above two scenarios are what we would expect. 

What we see with QNA-0 (cost 5) and TT-0-2 (cost 1): 

NCP> SHOW KNOWN CIRCUITS 

QNA-0 on 1.1 (VAXA) 

TT-0-2 on 1.2 (VAXB) 

NCP> SHOW KNOWN NODES 

1.1 (VAXA) reachable TT-0-2 1.1 (VAXA) 

1.2 (VAXB) reachable TT-0-2 1.2 (VAXB) 

Then if we toggle circuit TT-0-2 (state OFF then back ON): 

NCP> SET CIRCUIT TT-0-2 STATE OFF 
NCP> SET CIRCUIT TT-0-2 STATE ON 

and, 

NCP> SHOW KNOWN NODES 

1.1 (VAXA) reachable QNA-0 1.1 (VAXA) 

1.2 (VAXB) reachable QNA-0 1.2 (VAXB) 

and both circuits are still in an “ON” state with TT-0-2 still at a cost of 1 but 
reachable over circuit QNA-0. 
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Now, if you set circuit QNA-0 to state OFF, all nodes become unreachable. If 
you leave everything as is, it will log an event 4.14 Node Reachability Change 
after approximately 15 minutes and then circuit TT-0-2 will become the active 
circuit. However, if you turn QNA-0 back ON, circuit TT-0-2 (with a cost of 1) 
will become the active DECNET circuit. 

Solution: 

Apparently, NODRIVER has been modified on V4.4 VMS. The problem was 
seen when the executor buffer size and the segment buffer size were lowered 
to 192, as was suggested with earlier versions of VMS. Now with V4.4 VMS, 
we can leave the buffer sizes at 576 (default). This scenarios seen above went 
away when the buffer size was set to 576. 

How To Set Up ALIAS For Members of a VAXcluster with VMS 4.4 

How do you configure a cluster to be referred to by a name other than the 
specific node name of the individual cluster members? 

Description: 

With VMS Version 4.4, VAXCLUSTER members may now be referred to by 
a single node name. This node name is an ALIAS by which each member of 
a cluster may choose to be referred to. The cluster ALIAS address and name 
follow the same mles of any non-cluster DECnet node. The assignment of the 
ALIAS to a node is accomplished by using the NCP utility. NCP can make all 
references to this new cluster name permanent in the DECnet database. 
Procedure for using an alias: 

In order to use an ALIAS, one node within the cluster MUST BE a DECnet 
Level 1 router. This is accomplished with the following commands to NCP on 
that node. If routing is already enabled on one node within the cluster, this step 
can be disregarded. 

$ MCR NCP 

NCP> DEFINE EXECUTOR TYPE ROUTING IV !requires DECnet reboot for activation 
NCP> EXIT 

The following commands issued to NCP will establish the cluster ALIAS as a 
permanent DECnet node name in the database, and subsequent reboots of the 
node will allow ALIAS access. These commands should be invoked on each 
member node of a cluster that is to be referenced using the ALIAS. Member 
nodes that do not issue these commands will not participate in the ALIAS 
feature: 
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$ MCR NCP 

NCP> DEFINE ADDRESS area.number NODE cluster_nama 
NCP> DEFINE EXECUTOR ALIAS NODE cluster_name 

Note: 

By default, the ALIAS INCOMING parameter is enabled 
for a node if an alias node identifier has been defined 
for the node. The next command is only supplied for 
completeness and is not required. 

NCP> DEFINE EXECUTOR ALIAS INCOMING ENABLED 

Note: 

By default most network objects have ALIAS 
INCOMING/OUTGOING either disabled or enabled 
depending on the nature of the object. PHONE for 
example is by default DISABLED for both since it 
requires specific node interfacing to isolate the desired 
user. The following commands are not required but serve 
as an illustration for object access via the ALIAS: 

NCP> DEFINE OBJECT ALL ALIAS INCOMING ENABLED 

NCP> DEFINE OBJECT RHONE ALIAS INCOMING DISABLED {override RHONE 
NCP> DEFINE OBJECT ALL ALIAS OUTGOING ENABLED 

NCR> DEFINE OBJECT RHONE ALIAS OUTGOING DISABLED {override RHONE 
NCP> EXIT 

In order to activate the ALIAS, you must shutdown DECnet on each cluster 
node via the NCP command: 

$ MCR NCR SET EXECUTOR STATE OFF {shutdown ONLY DECnet on the node 

(or reboot the whole cluster at once with the SHUTDOHN.COM) 

After DECnet is shutdown (DCL command SHOW SYSTEM 
indicates process NETACP and REMACP are gone) restart it using the 
SYS$MANAGER:STARTNET.COM command procedure. 
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New Features in DECnet-VAX V4.4 
Description: 

Several new features have been added to DECnet-VAX V4.4. These new 
features include the addition of a cluster alias, changes to the permanent 
database, the ability to downline load using a software id, improved 
performance over asynchronous lines and satellite links, and a QIO interface for 
802 support. The following is a detailed description of the new features. 

• Cluster Alias 

A cluster alias enables nodes in a VAXcluster to be accessed using a single 
node name while retaining the ability to be accessed individually. The alias 
node name is perceived by other nodes in the network as representing a 
single node. When users specify the cluster alias as the remote node name, 
they will be connected to one of the cluster nodes that is currently available. 
Users no longer need to know which nodes in the cluster are active in order 
to successfully connect to the cluster. 

There must be at least one routing node in the cluster in order for the cluster 
alias to be available. The routing node maintains a table of all nodes in 
the cluster using the alias node name and advertises that it is exactly one 
hop away from the alias node. This results in all packets destined for the 
alias node being sent to this router. Connect request packets received are 
passed to nodes participating in the cluster alias in a round robin fashion. 

All other packets received for logical links created to the alias node are 
forwarded to the appropriate node in the cluster by the router. Because 
the existence of a router is required for the availability of the cluster alias, 
it is recommended that there are at least 2 routing nodes in the cluster 
to maintain the availability of the cluster alias. The second router will 
automatically replace the router that is handling the alias traffic in the event 
that it becomes unavailable. 

Because a minimum of two routing nodes are recommended when using 
the cluster alias, a change in the routing algorithm has been implemented to 
alleviate some of the overhead incurred by a routing node. The change in 
the algorithm causes the routing node to claim that it is infinite hops from all 
nodes in the network except itself and the alias node, and to send out routing 
update messages only when the broadcast routing timer expires, rather than 


VAX-19 



PAGESWAPPER - May 1988 - Volume 9 Number 10 
DECnet-VAX Tips 


every time there is a change in the network topology. The default value 
for the broadcast routing timer has been increased from 40 seconds to 180 
seconds. This algorithm is used when a router has only one active circuit. 

It is important to note that there is no automatic failover to other nodes in 
the cluster for logical links created using the cluster alias. If the node in the 
cluster handling the logical link goes down for any reason, another node in 
the cluster will NOT automatically take over the logical link. The logical 
link is terminated and the remote user must re-establish the connection to the 
cluster alias to get another available node in the cluster. 

By default, the EXECUTOR is set up to enable the node to accept incoming 
connections that are destined for the alias node. If the system manager does 
not want the node to accept incoming connections for the alias, then this 
feature must be manually disabled. 

Network objects may also be set up to use the alias node name. By default, 
most network objects will accept incoming connections destined for the alias 
node address, but the system manager must enable the use of the alias for 
outgoing connections. MAIL is the only network object that, by default, will 
use the alias for both incoming and outgoing connections. The alias should 
not be enabled for network objects, such as PHONE, that require multiple 
concurrent logical links to a single node. The reason for this is because 
incoming connections for the cluster alias are assigned in a round robin 
fashion to nodes in the cluster and there is no guarantee that all connections 
from the object will be created to a single node. If a proxy account is set 
up on a remote node using the cluster alias, the objects on the local node 
that would utilize the remote proxy account should be set up to use the alias 
node name for outgoing connections. This would enable the alias node name 
to be used in the connect request, rather than the actual node name. 

• Setting up a Cluster Alias 


• At least one node in the cluster must be set up as a routing node, though 
it is recommended that there be more than one routing node to ensure the 
availability of the alias node name. 
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• Define the alias node name and address in the node database. This 
definition, like any other node definition, must describe a unique node 
name and number. 

NCP> DEFINE NODE al±as_nama ADDRESS a.nn 

• Associate the alias node name or address with the executor and enable 
the node to accept incoming connections for the alias. 

NCP> DEFINE EXECUTOR ALIAS NODE aliaa_name 

• On smaller systems in a cluster or systems with few available resources, 
the system manager may want to prohibit the node from accepting 
incoming connections for the alias, though still allow it to use the alias 
on outgoing connections. 

NCP> DEFINE EXECUTOR ALIAS INCOMING DISABLED 

• Configure network objects to use the alias for incoming and outgoing 
connections. If proxy accounts are set up on remote nodes using the 
cluster alias, objects such as FAL, that enable a user to access a node 
using a proxy account, should have the use of the alias for outgoing 
connections enabled. This will cause the alias node name to be used in 
the connect request, rather than the actual node name. By default, all 
objects except PHONE will accept incoming connections for the alias. 
Mail is the only network object that, by default, will use the alias for 
outgoing connections. 

NCP> DEFINE OBJECT object ALIAS OUTGOING ENABLED 

Changes to the Permanent Database 

In DECnet-VAX V4.4, the permanent node database (NETNODE.DAT) 
has been divided into 2 separate files NETNODE_REMOTE.DAT and 
NETNODE_LOCAL.DAT. NETNODE_REMOTE.DAT contains all remote 
node information and, in a cluster, can reside in SYS$COMMON:[SYSEXE] 
so only one node database needs to be maintained for all the nodes in the 
cluster. This database should also contain an entry defining the node name 
and address of the executor. Node information can easily be propagated by 
copying this database to remote nodes. 
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The database NETNODE_LOCAL.DAT contains all of the executor 
information, except the actual node name. The node name is obtained 
from the entry in the file NETNODE_REMOTE.DAT which contains it. 

If there is redundant executor node information in the file NETNODE_ 
REMOTE.DAT entry, it is superceded by the information in the file 
NETNODE_LOCAL.DAT. This file resides in SYS$SPECIFIC:[SYSEXE] 
DECnet-VAX will convert NETNODE.DAT into NETNODE_LOCAL.DAT 
and NETNODE_REMOTE.DAT when DECnet-VAX V4.4 is started for the 
first time. 

• Improved Downline Load Capability 

A DECnet-VAX node can now provide load assistance to systems that are 
not defined in the node database, but supply a software id in the load request 
message, providing the load file is available on the node. When MOM 
receives a load request, it first looks for a software id in the request. If an 
id is present in the message, MOM verifies that the load file is present and 
then offers load assistance. If the load file is not present, it will ignore the 
load request. If a software id is not present in the load request, MOM will 
check the node database for an entry for node making the request. If an 
entry exists, MOM will offer load assistance using the information contained 
in the database entry. 

Currently, only DECServers provide a software id in the load request. 

• Improved Satellite Link Performance 

A new parameter, TRANSMIT PIPELINE, has been added to the SET LINE 
command to enhance performance over DMR11 lines for satellite links. The 
system manager can now set the number of DDCMP messages that can 
be transmitted over the DMR11 line before an acknowledgement must be 
received. The optimum value for this parameter can be calculated by using 
the following algorithm: 

MESSAGES = (DELAY*RATE)/(SIZE*8) 


VAX-22 



PAGESWAPPER - May 1988 - Volume 9 Number 10 

DECnet-VAX Tips 


DELAY = Link's total round trip delay time in seconds. It 
can be determined from the information provided 
by the carrier or by monitoring the circuit to 
calculate the delay 
RATE = Line speed in bits per second 

SIZE = Size of average DDCMP message in bytes. This can 
be calculated by dividing the number of bytes 
transmitted by the number of tranamissions 

• Improved Performance for Asynchronous Lines 

The reply timeout for asynchronous circuits will automatically be 
recalculated if there is constant timeouts occurring on the circuit. This 
enhancement eliminates the need to use small transmit buffers on an 
asynchronous line and should help to improve performance over these lines. 

• 802 Support 

The Ethernet drivers have been enhanced to include a QIO interface for 802 
support. IEEE 802.3 and 802.2 packet formats are supported, and the source 
and destination address fields must be 6 bytes long. Neither the 2 byte nor 
the mixed 2 byte/6 byte address field formats are supported. IEEE 802.2 
Class I service is supplied by the driver. Class II service can be provided by 
the user if user supplied service is specified. 

The Ethernet physical characteristics have been adapted for the 802.3 
implementation. This means that physical layer for 802 is identified as type 
10BASE5 (lOMb/s baseband medium with a maximum segment length of 
500 m). 

Information on using 802 QIO interface is documented in the I/O User’s 
Guide. Currently, DECnet-VAX does not utilize the 802 support. 

• Miscellaneous 

Currently the DMV-11 is the only synchronous device supported by DECnet- 
VAX on the Micro VAX II and the VAXStation II; the DPV-11 is not 
supported as a DECnet-VAX device. In the future, higher performance 
synchronous devices will be available for the Micro VAX n and support for 
these devices will be added to DECnet-VAX. 

A full function kit (Q4D05) and an upgrade from end node to full function 
kit (Q4D09) will be offered for the VAXStation n. 
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DMB32 Sync Port Problem Under VMS 4.6, NMLRSP Error Message 
Symptom: 

This problem has been seen when the synchronous port of the DMB32 is 
configured with the default values in VMS 4.6. The following error is reported, 
when trying to bring the line and circuit up in NCP with STARTNET.COM: 

%NMLRSP, listener response message number 756C 

Analysis: 

The DMB32 is setup with a default of 4 Receive Buffers. This is not adequate 
for DECNET operation. 

Solution: 

The line DMB-n is configured with receive buffers 4, to correct the problem in 
NCP input the following commands: 

NCP> SET CIRCUIT DMB-n STATE OFF 
NCP> SET LINE DMB-n STATE OFF 

NCP> DEFINE LINE DMB-n PROTOCOL DDCMP POINT RECEIVE BUFFERS 8 STATE ON 
NCP> DEFINE CIRCUIT DMB-n STATE ON 
NCP> SET LINE DMB-n ALL 
NCP> SET CIRCUIT DMB-n ALL 

Engineering is aware of the problem. They expect this problem will be 
corrected in a future release. 

RMS-W-RTB ‘nnn’ byte record too large for user’s buffer error 
Symptom: 

The command: 

COPY filename remote__node: : disk: [directory] *. * 

results in the error: 

RMS-W-RTB 'nnnn' byte record too large for user's buffer. 

Analysis: 

The largest record in the file being transferred is greater than the SYSGEN 
parameter RMS_DFNBC. The default value for this parameter is 8 or 4096 
(8*512) bytes. Usually the default value is adequate but occasionally, large 
records are encountered, and when using DECnet, the value must be increased. 
The sysgen value RMS_DFNBC places an upper limit on the network buffer 
size for the system that will be used for network access to remote, sequential, 
indexed sequential, and relative files. It places an upper limit on the largest 
record that can be transferred to or from a remote file. Thus, the largest record 
that can be transferred must be less than or equal to RMS_DFNBC multiplied 
by 512 bytes. 
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Solution: 

Reset the value of RMS_DFNBC as appropriate on target VMS system. This 
parameter is dynamic and can be changed while the system is running by 
executing the following commands: 

SYSGEN> SET RMS_DFNBC 16 ! or whatever value is needed in 

! increments of 512 bytes. 

SYSGEN> WRITE CURRENT 
SYSGEN> WRITE ACTIVE 

SYSGEN> USE ACTIVE ! verify update 

SYSGEN> SHOW RMSJDFNBC 

Make sure that the values have indeed been altered in SYSGEN before 
executing the COPY command again. 

Footnote: 

The DCL command SHOW RMS will list current RMS default parameters 
in a table format. THE SYSGEN parameter RMS_DFNBC equates to the 
NETWORK BLOCK COUNT and is setable at the process and system level. 
Thus, if you need to quickly modify the network block count system wide use 
the command: 

$SET RMS_DEFAULT/SYSTEM/NETWORK_BLOCK_COUNT=n 
(where n is a multiple of 512 bytes) 

This will update the SYSGEN parameter RMS_DFNBC automatically and you 
may attempt the copy again, assuming the remote node has been updated too. 

NCP DEFINE LOGGING commands return RMS-F-AID error 
Symptom: 

While using the NCP DEFINE LOGGING commands the following error is 
seen: 

%NMLRSP, listener response, file 10 error using permanent database 
-RMS-F-AID,invalid area number ID=!UL 

Analysis: 

The SYS$SYSTEM:NETLOGGING.DAT file has become corrupted. 

Solution: 

DELETE or RENAME the SYS$SYSTEM:NETLOGGING.DAT file and invoke 
NCP again. DEFINE/SET the logging parameters desired. This will create a 
new version of the file and the error should not reappear. 
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ANALYZE/IMAGE Truncates Resulting File Over the Network 
Symptom: 

The following command produces a tmncated file when directed over the 
network: 

ANALYZE/IMAGE/OUTPOT=NODE::OUTJFILE IN_FILE 

An example using SYS$SYSTEM:LOGINOUT.EXE produces a file with an 8/9 
block allocation, whereas without the NODE:: specification the resultant file is 
13/15 in size. 

RMS defaults have no control of this scenario. The NETWORK_BLOCK_ 
COUNT was increased from 8 to 16. On executing the above command with 
NODE:: equal to 0::, the resultant file had a 0/0 block allocation. 

Other parameters checked were: SYSGEN MAXBUF = 8192, UAF BYTLIM 
= 10400, which are known to be acceptable in this environment. 

Analysis: 

The ANALYZE/IMAGE utility does not appear to close the file specified by 
/OUTPUT correctly and thus when the image mns down, only those buffers 
that have been written to the remote node are currently available. 

In the case of a local file, RMS mndown does all the necessary flushing. For 
the remote file, FAL does not appear to do the same thing for you, so you get a 
truncated file. 

Restriction: 

Use of ANALYZE/IMAGE and directing output over the network is 
unpredictable. The resulting file is truncated depending on its length and 
when the source node initiates a disconnect of the link. 

Solution: 

Engineering is aware of the problem. They expect this problem will be 
corrected in a future release. 

REMACP Fails or Disappears After Increasing SYSGEN’s MAXBUF 

After upgrading to V4.4, REMACP would “disappear” immediately after 
being started by RTLOAD.COM. It was determined that during the upgrade the 
SYSGEN parameter MAXBUF was increased to 5000. Reducing MAXBUF 
below 5000 fixed the problem but caused some needed applications to fail. 
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Description: 

REMACP allocates virtual memory at startup to hold the various data structures 
associated with remote terminals, including receive buffers and UCB’s. 

It calculates the number of pages as follows: 

((RJOBLIM*GL_VECSIZE*511)/512)+1 + ((RJOBLIM*MAXBOF*511)/512)+1 

Therefore, if you don’t have a large enough page file quota for REMACP, it will 
die. Other parameters that will kill REMACP would be insufficient working set 
limit or virtual address space full. 

You can increase the page file quota for REMACP by adding the line 

/PAGE_FILE = N 

to the file SYS$MANAGER:RTTLOAD.COM. Or you can up the SYSGEN 
parameter PQL_DPGFLQUOTA, which increases everyone’s quota. 

DEQNA Connected to BROADBAND Ethernet Causes Send Errors 

DEQNA connected to BROADBAND clocks short circuit errors in NCP. 

Description: 

When connected to BROADBAND the DEQNA NCP counters will report send 
errors (in particular “short circuits”) for each transmit. This is due to the LOSS 
OF CARRIER status caused by signal latency (propagation delay to and from 
HEADEND) in BROADBAND. 

Solution: 

Disregard this error when using the DEQNA on BROADBAND. 

Nonheartbeat Transceiver Required in LAN DELNI/DEMPR Setup 

Symptom: 

A DELNI/DEMPR ThinWire combination is connected to an Ethernet LAN. 
Communication from nodes on the DEMPR to nodes on the DELNI do 
not work. But nodes on the DEMPR can communicate to nodes on the 
Ethernet backbone and the same for nodes on the DELNI. The only lack of 
communication is local to those nodes on the DELNI/DEMPR combination. 
Analysis: 

DELNI/DEMPR ThinWire configurations do not require heartbeat. In this 
scenario the H4000 connecting the DELNI to the Ethernet backbone is 
providing heartbeat. 
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Solution: 

The DELNI/DEMPR combination requires a transceiver without heartbeat. The 
Digital H4000-BA is the transceiver that provides this functionality. Installation 
of a nonheartbeat transceiver with the DELNI/DEMPR combination should 
resolve this problem. 

MAIL/PHONE Troubleshooting For “Login Invalid At Remote Node” 
message 

Troubleshooting the MAIL or PHONE utility over the network. 

Description: 

ERROR RECEIVED: Login information invalid at the remote node. 

The first step is determine which node is at fault. MAIL and PHONE use 
the default DECNET account for network access so we can force a local and 
remote network access using this account as follows: 

DIR 0"":: 

Forces a directory of the default DECNET account on the local node. If the 
error occurs, then a problem exists at this end. 

DIR REMOTE"":: 

Attempts the same test on the remote. If the error occurs, then the problem 
exists at the remote end. 

If the error occurs with both tests then both nodes have problems and the 
following troubleshooting steps should be taken on each end: 

The most obvious cause for this error is that the account/password for the 
default DECNET account on the remote has changed or is inconsistent with 
what the NCP EXECUTOR database has stored for this type of access. Once 
this has been checked more detailed analysis is necessary to pinpoint the cause. 

Invalid login errors at remote are most oven due to changes in the SYLOGIN 
or user’s LOGIN.COM that are not valid for a NETWORK process. Since 
the error occurs during LOGINOUT.EXE the error would imply that there is 
a problem with the account/password rather than an error with a command 
file, and is somewhat misleading. One way to test this would be to edit 
the SYLOGIN.COM and enter a SET VERIFY to monitor execution 
of DCL commands during the network access. A failing command is 
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isolated in the NETSERVER. LOG file of the receiving account. In any 
case it is wise to include the following command as the first line of the 
SYS$MANAGER:SYLOGIN.COM file: 

$ IF F$MODE() . EQS. "NETWORK" THEN EXIT 

If the problem lingers the likely place to continue would be to use the 
AUTHORIZE utility to review the default DECNET account parameters: 

$SET DEFAULT SYS$SYSTEM 
$MCR AUTHORIZE 
SHOW DECNET 

The following parameters should be reviewed: 

• LGICMD Should be set to NL: (Null). 

• DEFAULT Should be set to either of the following devices as needed: 

SYS$SYSDEVICE:[DECNET] 

SYS$SPECIFIC:[DECNET] 

SYS$COMMON:[DECNET] 

and the directory MUST exist! 

The most common parameter problems causing this error: 

• TABLES should be set to DCLTABLES. Can be corrected by the following 
command: 

AUTHORIZE> MODIFY DECNET/CLITABLES=DCLTABLES 

• FLAGS should be set to LOCKPWD, and CAPTIVE. 

• NETWORK access should be set to FULL ACCESS for primary and 
secondary days all other forms of access like batch, local, dialup, and remote 
should be set to “no access” for primary and secondary days. 

• DEFAULT PRIVILEGES: NETMBX,TMPMBX 

• AUTHORIZED PRIVILEGES: NETMBX,TMPMBX 

• PWDCHANGE: Verify password has not EXPIRED or PRE-EXPIRED, or 
when in doubt MODIFY DECNET/PASS=password. 

If the error persists at this time use the NCP utility on the target node: 
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• In EXECUTOR CHARACTERISTICS check for NONPRIVILEGED USER 
ID and PASSWORD. The default setup should be (BYPASS required to 
view password): 

Nonprivileged user id: DECNET 

Nonprivileged user password: DECNET 
(This password should match the password 
by the AUTHORIZE utility for the DECNET 
default account,it does not have to be 
DECNET, just consistent in both places.) 

• Check the object characteristics in the NCP database as it should have the 
following minimum characteristics: 

Number = 27 or Number = 29 

File Id = MAIL. EXE File Id = PHONE. EXE 

Proxy Access = OUTGOING Proxy Access = Outgoing 

Alias Outgoing = ENABLED (where applies) 

Note: If ACCOUNT is indicated it must match what the EXECUTOR has set 
for Nonprivileged User. 

• If all else fails then check the protection on the following files, they should 
at least have the following minimum protections: 

SYS$MANAGER:SYLOGIN.COM (S:RWE,O:RWE,G:RE,W:E) 

SYS$ SYSTEM:NETSERVER.COM (S:RWE,O:RWE,G:RE,W:E) 

SYS$SYSTEM:NETSERVER.EXE (S:RWE,0:RWE,G:RE,W:E) 

SYS$SYSDEVICE:[000000]DECNET.DIR (S:RWE,0:RWE,G:RE,W:E) 

SYS$SPECIFXC:[000000]DECNET.DIR (S:RWE,0:RWE,G:RE,W:E) 

SYS$COMMON:[000000]DECNET.DIR (S:RWE,0:RWE,G:RE,W:E) 

Footnote: 

A NETSERVER.LOG file is created in the default DECNET account of the 
node receiving the connection and may contain the log of activities the user 
performed during the connection. Often it will provide more detail as to the 
cause of the error which can then be rectified. 

There are other causes for this type of failure but they are the exception and 
will not be discussed here. 
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Extra Characters Appear In Editor While SET HOST From VAX 
Symptom: 

Users on a VAXstation II are experiencing erroneous characters when SET 
HOST to VAX/VMS systems and running full screen editors like EDT 
and WPS. These characters appear when using the autorepeat feature of the 
keyboard and include “9”, and “=” at this time. The systems involved 
were running VMS 4.5 level software. 

Analysis: 

This scenario has been seen in Ethernet configurations and seems to be a timing 
issue between the VAXstation and the VAX system when SET HOST. 

Workaround: 

If a DECserver 100 or 200 is available in the configuration and users are 
allowed to connect to it via NCP then the following workaround is available 
until a solution is reached: 

While on the VAXstation use: 

• NCP to CONNECT VIA CIRCUIT QNA-0 PHYSICAL ADDRESS 
(DECserver address) 

• Use the required procedure/password to access the DECserver port and reach 
the LOCAL> prompt. 

• CONNECT “service” to a VAX/VMS node and mn the editor. 

Engineering is aware of the problem. They expect this problem will be 
corrected in a future release. 

DELNI/DEMPR ThinWire Configuration Guidelines 

ThinWire Ethernet DELNI/DEMPR configuration guidelines. 
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Description: 

When a DEMPR/DELNI combination is used heartbeat must be disabled. The 
H4000-BA can be ordered which does not have heartbeat or an H4000 can be 
modified as per FGO #FA-04744-01 to disable heartbeat. 

The following are 3 standard configurations: 

i 

base band Ethernet-*****- 

| transceiver with or without heartbeat 

I 

DEMPR 

(up to 8 coaxial segments can attach to DEMPR) 


base band Ethernet-****- 

| transceiver without hearbeat 
DELNI 

| (up to 8 DEMPRs connected to DELNI) 

I 

DEMPR 

(up to 8 coaxial segments can attach to DEMPR) 


(loop back connector on global port) 

(see note 1 below) 

DELNI 

| (up to 8 DEMPRs connected to DELNI) 

I 

DEMPR 

(up to 8 coaxial segments can attach to DEMPR) 

1 This needs more discussion. In order to get a standalone DELNI to work 
with DEMPRs the DELNI must be set in GLOBAL mode with a loop back 
connector on the global port (H3278 or P/N 12-22196-01). The reason the 
DELNI can not be put into LOCAL mode is because the DELNI would then 
provide its own heartbeat. 

2 NonThinwire VMS systems do not require heartbeat. Therefore in the above 
configurations it is legal to mix Thinwire and nonThinwire systems. At 
present if a non-Thinwire system is attached to a nonheartbeat transceiver 
the NCP LINE COUNTER COLLISION DETECT CHECK FAILURE will 
increment, however this does not indicate a problem. 
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Current Versions of Network Software Products 

Table 1-2 Current Versions of Networks Products as of February 10th, 1988 


Ethernet Terminal Server (DECSA) 

v2.2 

Router Server (DECSA) 

vl.2 

SNA Gateway (DECSA) 

vl .4 

X25 Gateway (DECSA) 

vl.O 

DECserver 100 

vl.3 

DECserver 200 

v2.0 

DECserver 500 

vl.O 

MUXserver 100 

v2.1 

DECrouter 200 

vl.O 

VAX/PSI 

v4.1 

RSX/PSI 

v3.0 

Terminal Server Manager (TSM) 

vl .1 

Remote Bridge Management Software 

vl .1 

Ethernim 

v2.0 

NMCC 

vl .1 

LAN Traffic Monitor (LTM) 

vl.O 

DECnet 

phase IV 

DECnet-VAX 

v4.7 

DECnet-Ultrix 

v2.2 

Table 1-3 Operating Systems 

VMS v4.7 

RSX 11M v4.3 

RSX 11M+ v4.0 

RSTS/E v9.4 

ULTRIX v2.2 


VMS V4.7 Upgrade: PATCH-W-DIFVAL Error On LTDRIVER 
Symptom: 

During an upgrade from Version 4.6 to Version 4.7 of VMS, the user receives 
the following error message: 

PATCH-W-DIFVAL, memory contains different values than specified. 

(for LTDRIVER) 
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Analysis: 

This message means that the Version 4.7 upgrade did not patch the LTDRIVER 
file. 

The root of the problem is that an LTDRIVER from the LATplus/VMS kit 
was present (LTDRIVER 1.1-23), or the LTDRIVER was version X7N-14 or 
greater. X7N-14 LTDRIVER is a maintenance release which would be obtained 
from DIGITAL support channels. The LATplus/VMS LTDRIVER versions are 
usually ‘LAT+ vl.x-yyy’. The V4.7 upgrade expects to find the copy of the 
LTDRIVER X6N-8, which is the version that shipped with v4.6 of VMS. 

To check which version of the LTDRIVER is present on the system, the DCL 
‘ANALYZE/IMAGE SYS$SYSTEM:LTDRIVER.EXE’ command can be used. 
The information needed is contained in the ‘Image Identification Information’ 
section. The field within this section that contains the version information is 
‘image file identification:’. 

Solution: 

If the LTDRIVER is X7N-14 or greater, no further action is needed as this 
version already includes all patches in the VMS 4.7 upgrade. If the LTDRIVER 
is not X6N-8 then the LTDRIVER from the v4.6 distribution should be restored 
and the v4.7 patches applied. 

Restore the V4.6 LTDRIVER and get the V4.7 patch file from the V4.6 and 
V4.7 distribution tapes, respectively. Apply the patch manually. 

$ Set Default SYS$OPDATE 

$ Mount/Foreign mtcu: label ! VMS V4.6 distribution tape 

$ Backup/Select=LTDRIVER.EXE mtcu:LIBRARY/Save []/Log 
$ Dismount mtcu: 

$ Mount/Foreign mtcu: label ! VMS V4.7 distribution tape 

$ Backup/Select=LTDRIVER.VUP mtcu:VMS047.A/Save []/Log 
$ Dismount mtcu: 

$ Define/User SYS$INPUT LTDRIVER.VUP 
$ Patch LTDRIVER 

$ Rename/Log LTDRIVER.EXE SYS$COMMON:[SYSEXE] 

SYSSSYSTEM may be substituted for SYS$COMMON:[SYSEXE] if this is 
not a cluster system. All systems must be rebooted to use the proper driver. 

For uVMS, the LTDRIVER.EXE image can be obtained from the UTIL046.K 
saveset and the LTDRIVER.VUP file can be UVMS047.A saveset. 
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If ANALYZE/IMAGE is run against the new image, the ident should be X6N-8 
with an DEC ECO level of ‘%x0000003F\ This will indicate that the patches 
applied by the 4.7 updates were successful. If this is successful, the system 
must be rebooted in order to load the new LTDRIVER image. 

VMSINSTAL Flags DECnet As Running When It Has Been Shut 
Down 

Symptom: 

When using VMSINSTAL.COM to install VMS updates or layered products it 
reports the message: 

Your DECnet network is running 

when proceeding through the installation. The network was shut down via 
the NCP command SET EXECUTOR STATE OFF, and the NETACP and 
REMACP processes do not show up on the system. 

Solution: 

The VMSINSTAL.COM command file translates the logical name SYS$NODE 
to determine if the network is still up and running. If the logical name is a 
null string, it assumes that the network has been shut down. If the logical 
name is defined on the system in some other fashion, the message may appear, 
although DECnet is not running. 

Deassigning the logical name via DCL will resolve VMSINSTAL.COM printing 
the message. The logical may be deassigned from an account with SYSNAM 
privilege as follows: 

$DEASSIGN/SYS/EXEC SYS$NODE 

Circuits Remain ON-SYNCHRONIZING After STARTNET.COM is Run 
Problem: 

After STARTNET.COM is run, all the lines and circuits appear in the database, 
but NCP indicates that all the circuits are in an ON-SYNCHRONIZING state. 
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Suggestion: 

Verify that the executor is on by entering the NCP command “show executor 
status”. 

If the NCP database has defined for the executor STATE OFF, STARTNET will 
load all the NCP characteristics into the running system, but the executor will 
be off. In some cases an NCP SET EXECUTOR STATE ON command will 
correct the condition, and the circuits will initialize. 

In any case, be sure to use the NCP DEFINE EXECUTOR STATE ON 
command to permanently set the executor state to ON for future restarts of 
DECnet. 

How To Deny SET HOST By A User or Multiple Users 

How to prevent a single user or several users from using SET HOST function. 

Description: 

By associating an ACL with the SYS$S YSTEMiRTPAD.EXE task and giving 
that user no access privileges, you will prevent that user from invoking the 
RTPAD executable for outbound SET HOST. 

Note: 

This will not go into effect until the next time the user logs in. 

IEEE Ethernet Interface And H4000 Transceiver Compatibility 

Use of IEEE Ethernet transceiver instead of H4000 transceiver on Ethernet 

Description: 

Some sites may be using the IEEE standard Ethernet transceivers instead of 
H4000 transceivers. The IEEE transceiver operates basically the same as the 
H4000. 

The only noticeable difference between the H4000 transceiver and the IEEE 
standard transceiver is, when the IEEE standard transceiver is used there will be 
as many COLLISION DETECT CHECK FAILURES on the UNA-X line as the 
number of packets sent on that line. 

The reason for the appearance of the collision detect check failures on the line 
is that the “collision test generator” is turned on at the end of each transmission 
on the H4000 transceiver to simulate a collision condition. 
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The IEEE transceiver on the other hand does not generate the collision test 
signals, and as a result the DEUNA/DELUA will register a collision check 
failure for every packet sent on that line. Thus, these errors can be ignored in 
this configuration. 

The collision test generator signal is also called the “heartbeat” since it occurs 
on a fairly regular basis. 

Circuits Remain ON-SYNCHRONIZING When Turned On 
Problem: 

When attempting to turn on a circuit, the circuit remains in ON- 
SYNCHRONIZING state. 

Suggestion: 

First check that the LINE associated with this circuit is ON, and 
attempt to set it ON if it is not. If the system in question has several 
other circuits already defined and running, check the settings for the 
SYS$MANAGER:LOADNET.COM logicals that adjust the working set size 
for the NETACP process. In some cases when there are many circuits, the 
NETACP process will need more resources to allow the circuit to initialize. 
NCP LIST Fails With NMLRSP, File I/O Error, Permanent Database 
Symptom: 

When executing a LIST or DEFINE on the permanent DECnet database using 
NCP the user gets following error: 

%NCP-I-NMLRSP, Listener response file I/O error, permanent database 
-RMS-W-RTB ! UL Byte record to large for user buffer 

The above error occurs whenever an NCP LIST or DEFINE is attempted. Yet 
the volatile database is correct and can be assessed and modified. 

Analysis: 

SYS$SYSTEM:NETNODE_REMOTE.DAT is corrupted. The error is a result 
of RMS posting a $GET on the file and having trouble opening the file. 

Solution: 

To see if this is the problem rename the NETNODE_REMOTE.DAT and try a 
LIST. If this proves to be the problem the file should be rebuilt locally using 
the NCP DEFINE command, or the NCP COPY KNOWN NODES command 
may be used. Either approach will create a new copy of the NETNODE_ 
REMOTE.DAT in its absence. 
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How To Compile And/Or Link Over the Network 
Description: 

It is possible to compile and link programs over the network using DECnet in 
an effort to offload compute intensive processes; however, some restrictions 
apply. Namely, compiled or linked images cannot be directed over the network 
directly with the compile or link commands. Only the input file can be obtained 
via the network, and the resulting image left on the system that processed the 
compile or the link. The executable image can then be copied to the desired 
system. 

For example, let’s say that VAXA is the busy node and VAXB is a less busy 
remote node: 

• Log on VAXB, and compile a file located on VAXA: 

$ CC VAXA"USER PASS"::ddnn:[directory]FILENAME.C (C program example) 

This will use VAXB’s C compiler, and the output will reside on VAXB. 

• Log on VAXA, and link the object (.OBJ) file located on VAXB: 

$ LINK VAXB"USER PASS"::ddnn:[directory]FILENAME.OBJ 

This will use VAXA’s linker, and the output will reside on VAXA. 

Footnote: 

A DCL command procedure can be developed to prompt for a compiler type 
and file name. It can then trigger a remote task to compile and link the program 
name passed, and once complete send the resulting executable image back to 
the local node. 

OPCOM Prints Stored DECnet Events On The Console 
Symptom: 

Old DECnet events print on the console after the printer is turned on. 

Analysis: 

When DECNET event logging is enabled NCP>SET LOGGING MONITOR 
STATE ON event messages are sent to the CONSOLE printer via OPCOM. 

If the printer is turned offline the messages continue to be logged and saved 
by OPCOM. When the printer is turned back on, all of the messages that were 
generated while it was offline will still print out until real time is reached. 
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Solution: 

The way to clear the messages that would be printed is to stop the OPCOM 
process. STOP/ID=PROCESS_ID. OPCOM can be restarted by doing 
@SYS$SYSTEM:STARTUP OPCOM. When the printer is turned back online, 
everything will return to normal and only current events will be logged. 

How To Determine NUM_ETHERNET 

What is NUM_ETHERNET and where does it come from? 

Description: 

NUM_ETHERNET is the total number of Ethernet devices shown in a SHOW 
DEVICES/BRIEF that is performed when AUTOGEN.COM is executed. The 
value of this number is not a limit of any kind. It is only a reflection of 
the number of Ethernet devices that are present on the system at the time 
AUTOGEN is executed. 

Ethernet devices include XEcu, XQcu, ETcu, etc. 

FAL Access From VMS To DECnet-DOS Gets STACKDUMP With V4. 
Symptom: 

DIRECTORY from VMS to DECnet-DOS gets STACKDUMP/VMS FAL 
problem 

Analysis: 

When attempting access to DECNET-DOS FAL from a VMS system you may 
see a STACKDUMP intermittently. For instance, when attempting a DIR/FULL 
of a DECNET-DOS system from a DECNET-VAX system the following error 
may be seen followed by a STACKDUMP: 

%SYSTEM-F-ACCVIO, access violation, reason mask = 00, 

virtual address = 00000003, pc = 0000280A, psl = 13C00009 
Improperly handled condition, image exit forced 

This will usually end up with the user having to log back into the VAX. 

Solution: 

The problem has been traced to VMS receiving only device-name and file-name 
messages in directory list (no directory-name). The problem has been fixed for 
VAX/VMS V4.6. 
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How To Configure A DMB32 Synchronous Port 
Description: 

The DMB-32 has one synchronous port, eight asynchronous ports and one 
parallel printer port. The SIDRIVER is used for synchronous communications 
and must be installed as a layered product in order to use the controller’s 
“synchronous port” (See VMS 4.5 Release Notes, page 3-7). 

The SIDRIVER.EXE is NOT bundled as part of the VMS operating system and 
must be purchased and installed with VMSINSTAL separately (See the software 
installation kit that comes with the driver for installation details). 

VAX/VMS requires that an adapter cable be connected to the synchronous 
port before it will configure the synchronous device (SIxO). This means that a 
normal AUTOCONFIGURE in SYSGEN will not configure the synchronous 
port until a cable is attached on the bulkhead port. The DMB-0 line and circuit 
can then be configured using the Network Control Program (NCP). 

The Asynchronous ports and the Printer port are configured normally. The 
NODRIVER is used for DECnet, (DDCMP) asynchronous communications. 

Note: 

Modem control is provided on all synchronous and asynchronous ports for 
Public Switched Telephone Networks, or private leased lines. 

DECSA Router Server Used As An SNA Gateway 
Description: 

A DECSA Router Server used as an SNA Gateway node must be configured in 
the same “area” as the HOST node because the server uses DECnet protocol 
instead of LAT protocol. 

Note: 

The SNACSV.DIR, located on the HOST, must have privileges for WORLD set 
to READ, EXECUTE. This directory is where the SNA Gateway configuration 
files are placed on the Host. 
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Local Area VAX Cluster Guidelines 
Description: 

All Micro VAX II and VAXstation II systems in a Local Area VAXcluster 
configuration must use Revision E (or later), DEQNA Ethernet communications 
interface for supported operation. 

The Local Area VAX Cluster software Version 4.5A/4.6/4.7, must be installed 
on the boot node and the proper update kit must have been applied. (See the 
Local Area VAXcluster Manual on how to install or upgrade the VMS Version 
to LAVc.) 

The Local Area VAX Cluster Software KEY must also be installed on the boot 
node for cluster operation. The saveset name for the KEY is LAV010. 

The Micro VAX 2000 or VAXstation 2000 must be installed with the Version 
4.5C/4.6/4.7 installation/update kit for supported LAVc operation. 

The DECnet-VAX network must be up and mnning, if already installed, 
with the QNA-0, UNA-0, or BNT-0 circuit on the boot node set to service 
ENABLED so that the boot node will accept and process the boot request from 
the satellite node, and downline load the required root directories as identified 
in the SYS$SPECIFIC: [SYSMGR]NETNODE_UPDATE.COM file. This file is 
created when SATELLITE_CONFIG.COM is used for the first time to add the 
satellite node(s). 

All nodes in a LAVc must be configured in the same DECnet Area. 

Mail Received With Header And No Text 
Symptom: 

A user sends mail to another node, and the recipient of the mail receives only 
the header, and no text. 

Analysis: 

This can be caused by the default DECnet account (or the account used for 
default access by the MAIL object) having its device/directory specified in the 
authorization file as “NL:”. This allows for the MAIL header to be written out, 
but since the text cannot be written to a temporary file, it is lost. 
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Solution: 

To correct this, make sure the default MAIL account has a working directory 
for the writing of temporary files. 

STARTNET Stuck In A Loop,“Permanent Database Not Configured” 
Symptom: 

After upgrading to VAX/VMS and DECnet V4.4 attempts to start the network 
with SYS$MANAGER:STARTNET.COM returns an error message: 

“You have not configured your DECNET permanent data base. You must 
either use NCP to define your DECNET database, or invoke the procedure 
SYS$MANAGER:NETCONFIG.COM, which will do it for you.” 

You comply by configuring it with one of the two methods and try to start 
the network again and again get the same error message about configuring the 
permanent database. It seems to be stuck in a loop. 

Analysis: 

With V4.4 of VAX/VMS the STARTNET command procedure does an 
IF F$LOGICAL of (“NETNODEJLOCAL”). If it does not find one it 
goes to NO_DATABASE: which gives the above error message. In V4.4 
VMS, NETNODE.DAT was broken up into NETNODE_LOCAL.DAT and 
NETNODE_REMOTE.DAT and these new DECnet permanent database files 
are not being found. What has most likely happened is that either an old 
version of STARTNET.COM exists which looks for NETNODE.DAT, or a site 
specific STARTURCOM from an older version of VMS is being called. 
Solution: 

Verify that V4.4 STARTNET.COM supplied with V4.4 VAX/VMS is being 
invoked. If it has been purged it should be retrieved from V4.4 distribution 
media. 

If this checks out there may be corruption with one of these new files. In 
this case they should be renamed or deleted and NETCONFIG.COM or NCP 
invoked to create new copies of the files. 

DEBNT Microcode Incompatible With Driver When Reboot after VMS 
V4.5 upgrade 
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Symptom: 

A warning message “DEBNT Microcode incompatible with driver” will appear 
during re-boot after VMS V4.5 upgrade. 

Information: 

This warning message will appear with revision level 38.3, 38.4, and 40 of 
the DEBNT Firmware Microcode. The revisions before revision 40 will cause 
NOBUFPCKT Bugchecks when trying to access the DEBNT with VMS V4.5. 
The message will appear with every revision of the DEBNT microcode less 
than revision 100, which is available with VMS V4.6 distributions. 
NOBUFPCKT Bugcheck With VMS 4.4/4.5 Using DEBNT And 
ETDRIVER 

Symptom: 

VAX/VMS V4.4 or V4.5 systems with DEBNT Ethernet controller crash with a 
NOBUFPCKT Bugcheck when attempting NCP commands to the EXECUTOR 
or BNT circuit or line. 

Analysis: 

The crash dump will list NETACP as the current process and the stack pointers 
will show ETDRIVER as the culprit. The problem has been isolated to 
compatibility problems between the different versions of the DEBNT Firmware 
Microcode and the different versions of the ETDRIVER.EXE image file. 

Solution: 

If running V4.4 VMS, the ETDRIVER.EXE image file should have an image 
identification of X-13C. This is a patched image to make the ETDRIVER 
compatible with the DEBNT and 4.4. If running V4.5 of VMS, the ETDRIVER 
image identification should be X-15. This is the ETDRIVER.EXE delivered 
with the 4.5 release. Note: Use ANALYZE/IMAGE ETDRIVER to determine 
the value of the image identification parameter. 

The revision level of the Firmware Microcode for the DEBNT should be at 
revision 40 or above. Revision level 38.3 or 38.4 will cause the bugcheck 
problem. 
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AUTOCONFIGURE Does Not Configure XGDRIVER For DMF32 
Description: 

The XGDRIVER is the driver for the Synchronous EIA Port on the DMF32 
controller and is used by several products: PSI, DECnet and 2780/3780. 

When the DMF32 is installed, there are switch settings to configure which ports 
on the DMF32 will AUTOCONFIGURE. This is documented in the DMF32 
Users Guide (supplied with the DMF32) in Chapter 2. Ports that the DMF32 
has to select from are the Synchronous EIA Port (XG), 0-7 Asynchronous Ports 
(TX) and Printer Port (LC). The setting of switch pack S3 determines which 
ports are activated. 

For example, if the SYNC. Port, Printer Port and ASYNC. Ports are needed 
switch pack S3 should have switches 4 and 5 OFF. There are different 
combinations for ports that can be enabled or disabled. Refer to the DMF32 
Users Guide Chapter 2 or call DEC Field Service. 
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A SIG Information Interchange 

Mail written I/O submissions (indicating related I/O number(s) if any) to: 

Larry Kilgallen, Pageswapper Editor 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
USA 

To register for on-line submission to the Pageswapper dial: 

(617) 262-6830 

(in the United States) using a 1200 baud modem and log in with the username 
PAGESWAPPER. 


Does Anyone Use Defragmenter Programs? 

Antecedent IO(s) published in: Pageswapper Volume 8 Number 9 (April, 1987) 
through: Pageswapper Volume 9 Number 9 (April, 1988) 

BACKUP/RECORD & /FAST operation 

# 585.29 dated 4-MAR-1988 23:55 
From: Recurring contrapuntal themes 

In 585.27 John posed the suspicion that BACKUP/RECORD keeps track of 
file header information between the time the file is backed up and the time 
the recording pass occurs. This is not correct. BACKUP constructs a list of 
file-IDs during its backup pass which it later uses for /RECORD (and marking 
RMS journal files as being backed-up as well). But it does not store retrieval 
information. 

The reason for the original user’s VAXCluster disk corruption problem in the 
presence of Rabbit-7 must be explained by some other theory. 
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Also, the use of /FAST does not change the inner workings of BACKUP 
very greatly at all—the only difference is that in /FAST mode, BACKUP 
makes a serial search of all files in file-ID order to match files against the file 
selection criteria. /NOFAST causes BACKUP to create the selection list by 
scanning directory files instead. After the selected files list is created, there is 
no difference whatsoever. 

Wef Fleischman 
Software Techniques, Inc. 

6600 Katella Ave. 

Cypress, CA 90630 
714/895-1633 


what’s happening 
# 585.33 dated 10-MAR-1988 12:02 


From: John Osudar 

BACKUP certainly doesn’t retain headers from the save pass to the record 
pass (where would it put them all?!), but what it DOES do, of course, is read 
the header, change the backup date, and write the header (whether directly or 
through appropriate file system calls)—and the assumption is made that the 
header, once read, doesn’t change before it’s written out again. I suspect that 
the disk compressor bypasses whatever mechanisms exist for assuring that this 
is true—so the sequence is, BACKUP reads the header to prepare for recording 
the date; disk compressor moves the file; BACKUP rewrites the header with the 
new backup date and the old retrieval pointers. 

John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A-051 
Argonne, IL 60439-4837 
(312) 972-7505 


Digi-Data Gigastore System 

Antecedent IO(s) published in: Pageswapper Volume 9 Number 2 (September, 1987) 
through: Pageswapper Volume 9 Number 9 (April, 1988) 


A Gigastore problem and solution 
# 704.23 dated 2-MAR-1988 15:56 


From: John Osudar 
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Just had our first serious problem with the Gigastore. Last weekend we 
scheduled automatic backups of our 785’s three user disks. The first of the 
three disks, an RP07 that’s 94% full (954000 blocks used!), required more 
than a full six-hour tape (actually, only about 2/3 of the disk fit onto the tape). 
This is in comparison with the usual backup time of about two hours for the 
entire disk. Naturally, this was quite disturbing. I checked everything I could 
think of—and found that there were no tape errors logged by VMS, that the 
BACKUP process was the only non-system process running during that entire 
time, and that BACKUP used less than 10% of the CPU during its run. The 
SPM record of disk activity showed that through most of the mn, disk activity 
was far below normal. All in all, it appeared that the Gigastore drive had just 
plain slowed down, from its rated 120Kb/sec to something around 20Kb/sec. 

I spoke to someone at Digi-Data and got a reasonable explanation for the 
problem: 

In preparation for this month’s backups, I had followed recommendations 
contained in the Gigastore manual that suggest cleaning the drive with 
a commercial VCR cleaner (which they supply) every 20 hours of use. 
Apparently, the Gigastore read/write heads are very sensitive, and cleaning 
the drive does far more bad than good. So it appears that the reason for the 
great slowdown in Gigastore throughput was that the drive was detecting errors 
with its read-after-write logic, and retrying the write operations repeatedly. 

Digi-Data claims that they use the Gigastore in-house daily for months at 
a time without cleaning the drive. Their recommendation is to watch drive 
performance carefully, and avoid cleaning the drive until performance drops off 
measurably; then, clean the drive as documented, and follow by writing (several 
hours?) of junk data to a scratch tape, to re-“break in” the heads. I tried this 
technique, and last night I backed up my RP07 in one hour and 38 minutes. 

One other comment about Gigastore throughput: from our experiences, it 
appears that a very significant factor in BACKUP throughput is the degree of 
fragmentation of the disk being backed up. The RP07 in question took over 
two hours to back up when it hadn’t been compressed for about three months. 
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Now, after compressing it a month ago, the drive is more full than at the last 
backup, but it took considerably less time to back up. 

John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A-051 
Argonne, IL 60439-4837 
(312) 972-7505 


Gigastore progress report 

# 704.24 dated 10-MAR-1988 12:46 


From: John Osudar 

Just completed our first set of post-“cleaning incident” (see .23) full-volume 
backups to the Gigastore. This time around, I broke out the /VERIFY pass as a 
separate /COMPARE, and got timings for everything. Here are some results: 

disk type % full time to back up time to compare time to restore 


RA81 

90 

93.7 

minutes 

106.1 

minutes 

96.9 

minutes 

RP07 

94 

99.7 

minutes 

110.6 

minutes 

103.2 

minutes 

RA81 

84 

81.7 

minutes 

91.5 

minutes 

82.4 

minutes 


Each disk had been compressed about a month earlier; each backup/ 
compare/restore job was mn on an essentially idle system (actually, run 
overnight at base priority 15 with only networks, SPM, and similar stuff active). 

Since it’s the backup pass that’s important (as that determines how much of the 
tape is used), this says that the three disks took just over 3/4 of one six-hour 
VHS tape. I’d settle for that kind of throughput any time! 

(The interesting thing will be to see what happens to these figures when we 
reinstall our Gigastore on our new 8350 system, where it will mn in a BI 
Unibus adapter on a processor that’s rated at 80% of our 11/785 in speed!) 

John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A-051 
Argonne, IL 60439-4837 
(312) 972-7505 


Has anybody used the SIDRIVER 
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Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) 


vl.0-7 driver is available for an SPR 

# 859.12 dated 7-MAR-1988 17:50 


From: gerson cohen 

In response to an SPR, I have received a new sub-release for the SIDRIVER 

labelled 1.0-7. While this does not seem to fix my application, its release notes 

mention a slew of problems that make me wonder how the product even got out 

of the door. Suggestion - if in doubt file an SPR, mine was answered within 

one week! 

gerson cohen 
nih 

bldg 2 rm 312 
bethesda md 20205 
301-496-4295 


VMS 4.7 is here! 

Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) 
through: Pageswapper Volume 9 Number 9 (April, 1988) 

I’ve seen that before 

# 866.66 dated 11-MAR-1988 18:40 

From: John McGrath 


RE: 866.60: 

“ it gets confused (at very random times) and begins 
kicking off batch jobs with “licensed number of users 
exceeded”. It’s never suppose to limit batch jobs. So 
either manually enforce the 2 ” 

I’ve seen a similar problem in V4.6. It seems to happen when you exceed (yes, 
exceed) the interactive limit. Say you are licensed for 16 users. If you try to 
login when there are 16 interactive users logged in, it does actually create the 
17th interactive process. LOGINOUT runs in that process, and tells you that 
you can’t log in. While that 17th interactive process is running, you can get 
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“Licensed number of users exceeded” in network jobs. I have not seen it in 

batch jobs, but I would not be surprised if it occurred there also. 

John P. McGrath 
Software Consulting Services 
3162 Bath Pike 
Nazareth, PA 18064 
(215) 837-8484 

ARE 4.6 SYMBIONT PROBLEMS REALLY GONE??? 

Our latest version of LATSYM/LTDRIVER 

# 897.2 dated 14-MAR-1988 14:09 

From: Frank Hattyar 

We chased Colorado Springs around on some problems and they sent us 
LATSYM V2.3 and LTDRIVER X7N-15 as the latest versions. Neither seems 
to be in VMS 4.7. Is there indeed a LATSYM V2.4 out there? 


Frank Hattyar 
Wells Fargo Bank 
1415 King Avenue 
Napa, CA 94559 


V2.4 exists 

# 897.3 dated 14-MAR-1988 22:02 

From: Dale E. Coy (505) 667-3270 

We got a new LATSYM.EXE from Colorado Springs (actually from the Dallas 
office but the Springs called them). Its Image File Identification: “V2.4-001”. 

The LTDRIVER.EXE which came with it is “LAT X7N-15”. 

I’m not about to say that it fixed any problems (it may have fixed some and 
created others). 

DALE E. COY 

LOS ALAMOS NATIONAL LAB 
PO BOX 1663, MS J957 
LOS ALAMOS, NM 87545 
505-667-3270 
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DIGITAL has it now, but it doesn’t work yet. 

# 897.4 dated 17-MAR-1988 10:40 

From: George Bone 

We received (and installed) LATSYM 2.4-001 and LTDRIVER X7N-17 from 
C. Springs. Unfortunately it doesn’t seem to fully fix the problems , as we 
had a LATSYM crash 4 days after 2.4 was installed. After 4 calls and 5 hours 
of waiting, we finally got someone in C. Springs. They said that LATSYM 
2.5 would fix our problems (??!??!??). A week later when it had not arrived, 

I called C.S. again and (after 4.5 hours callback time) they told me that 2.5 
would only fix the problem if DELETE/ENTRY on a stalled queue caused the 
crash. Later that day I ascertained that this did not seem to be our problem (I 
tried doing it, but no crash). I called C. S. to inform them and get encouraging 
words. 5 hours later (Does this seem to be a trend?) they called back and said 
Engineering was not releasing 2.5 AT ALL! They suggested submitting an SPR 
with a copy of the LATSYM.DMP file. NOW I find out (fortunately before 
sending the tape and SPR) that the LATSYM.DMP file contains remnants of the 
documents being printed at crash time. Since we have classified material on our 
system, this means that I can’t send out our dump. I’m waiting to hear from C. 
S. today, but I don’t know just what is going to happen. 

Anybody know of a good deal for a WANG? 


George Bone 

Code 2301.2 Mail Stop T-11 
Mare Island Naval Shipyard 
Vallejo, CA 94592-5100 
(707)646-2531 


VT100 Emulators for the Mac 

Antecedent IO(s) published in: Pageswapper Volume 9 Number 9 (April, 1988) 

Digital Hears It Now? 

#911.17 dated 10-MAR-1988 11:14 

From: Bill Mayhew 
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RE: 

“ By the way the board is switch selectable for thin wire 
or thick wire (DEC, ARE YOU LISTENING...) ” 

At least part of DEC seems to be listening... we were notified a few weeks ago 
that MicroVAX/VAXstation 2000s manufactured after some date in January ’88 
would support either thinwire or ’classic’ Ethernet. Not retrofittable, though. I 
have not actually seen one of these to determine how they implemented it. 


Bill Mayhew 

Village Systems Workshop Inc 
PO Box 642 
Natick MA 01760 
617-237-0238 

Digital had it THEN - but didn’t tell anyone. 

#911.18 dated 10-MAR-1988 18:53 

From: Dale E. Coy (505) 667-3270 

The DEPCA-AA consists of the board, card guide, ... AND: AUI Transceiver 
Cable and AUI Connector/Bracket Assembly 

The latter gadget is an additional metal panel which fits in the back of the PC 
(after removing the blank one), and has a regular transceiver connector - with 
ribbon cable to plug into the DEPCA. It thus takes up two back-panel holes, 
but it IS a standard transceiver connection 

The DEC designers were listening. This has been available all along. It is NOT 
something brand new for the DEPCA (my book was printed Dec. 1986). 

Of course, it seems that the message never made it from the designers through 
the sales force to the customer - but that’s not a hardware problem! 


DALE E. COY 

LOS ALAMOS NATIONAL LAB 
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PO BOX 1663, MS J957 
LOS ALAMOS, NM 87545 
505-667-3270 


PCFS and File Locking 

# 914.0 dated 23-FEB-1988 17:00 
From: Howard W. Pinsley 

Does anyone have any info on whether PCFS does file locking. I am interested 

in preventing two VAXMATE users from accessing the same file on a virtual 

disk and also in preventing a Vax accessor to the file in the server directory. 

Howard W. Pinsley 
145 West 79th. Apt 11D 
New York, NY 10024 


Details? 

# 914.1 dated 23-FEB-1988 19:44 

From: Dale E. Coy (505) 667-3270 

Can you clarify the question a little? Are you interested in preventing 
simultaneous access by multiple users, or sequential access? Are you concerned 
with executables, or data files, or both? 

Files accessed thru PCFS can be private (in a user’s VMS personal area, via 
the login password mechanism) or public, and protected in some ways (but not 
currently all VMS mechanisms). If you’ll describe exactly what you’re trying 
to prevent, and what you are trying to allow, I’ll try to give a better answer. 

DALE E. COY 

LOS ALAMOS NATIONAL LAB 
PO BOX 1663, MS J957 
LOS ALAMOS, NM 87545 
505-667-3270 


WordPerfect Locking 

# 914.2 dated 24-FEB-1988 10:25 
From: Howard W. Pinsley 
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I’m trying to prevent simultaneous access to the same data file (in this case 
WordPerfect documents). I would like multiple vaxmate users to be able to edit 
documents stored on a virtual disk—but obviously not at the same time. 

To make matters more interesting... I would also like to use the VMS version 
of WordPerfect to also access the PC wordperfect documents on the virtual 
disks (note that this does indeed work, locking issues aside). Thus the ultimate 
would be to give anyone who is running Wordperfect, either on a Vaxmate or 
a Vax, the ability to edit any Wordperfect document stored in a shared virtual 
disk. 

Any ideas? 

Howard W. Pinsley 
145 West 79th. Apt 11D 
New York, NY 10024 


OK - it seems reasonable. 

# 914.3 dated 24-FEB-1988 21:20 

From: Dale E. Coy (505) 667-3270 

Well, I understand what you’re trying to do. It’s not obvious from the 
documentation exactly what the situation is, but I’ll try to set up a test case in 
the next couple of days and let you know. 

By the way, I presume that you’re aware that (in its present incarnation) PCFS 
is a file server, not a virtual disk server, although that’s a subtle distinction. 
The VMS files are stream record format (I presume that won’t give VMS WP a 
problem). 


DALE E. COY 

LOS ALAMOS NATIONAL LAB 
PO BOX 1663, MS J957 
LOS ALAMOS, NM 87545 
505-667-3270 


I still wonder if PCFS has been ” fixed" 

# 914.4 dated 24-FEB-1988 21:57 


From: Larry Kilgallen 
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Dale, do you know if PCFS still uses a single server process for all users, or 

has it been converted to separate processes for each user? The original single 

server interacted badly with audit alarms. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


Please define "interacted badly"... 

# 914.5 dated 25-FEB-1988 09:46 

From: Bill Mayhew 

Larry, can you expand a little (let me rephrase that—please expand...) on “the 
original single server interacted badly with audit alarms.” 

VMS Services V2.0, which is currently in beta test, is supposed to solve most 
of the performance problems resulting from a single server process, but the 
information I’ve read _suggests_ that the solution is properly multi-threading 
a single server process. I’m not intimate with the product nor with what’s in 
the new release, but am interested in any comments you might have about 
an inherent design problem in a single-server-process scheme w/r/t security 
audits. “The competition” makes a good deal of noise about the single- vs. 
multiple-server-process issue, and I’m not convinced how much of it is “real” 
vs. “noise”. 


Bill Mayhew 

Village Systems Workshop Inc 


PO Box 642 
Natick MA 01760 
617-237-0238 


V2.0 of PCFS and DECNet-DOS 

# 914.6 dated 25-FEB-1988 21:43 

From: Dale E. Coy (505) 667-3270 

There isn’t a new version yet, so any prior problems still exist. However, the 
announcement of V2.0 specifies: 
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Support of NETBIOS, async DECnet connections, third-party Ethernet cards 
currently supported by DECnet-DOS (note: 3Com and Micom), faster file 
server and “new” virtual disk, sharing of PC files across a VAXcluster (note: a 
big improvement), diskless boot for DEPCA-card-equipped PCs, better terminal 
emulation, keyboard mapping (non-DEC keyboards), better LAT. 

The answer to your question is probably what I’ve left to last. I quote: 
“Security will be improved through the support of VMS Access Control Lists.” 

My understanding is that it will probably be a multi-threaded approach, which 
matches DEC’S tradition and (as far as I can see) doesn’t have any inherent 
drawbacks. 

DALE E. COY 

LOS ALAMOS NATIONAL LAB 
PO BOX 1663, MS J957 
LOS ALAMOS, NM 87545 
505-667-3270 

How VMS Services for MS-DOS interacted badly 

# 914.7 dated 25-FEB-1988 21:46 

From: Larry Kilgallen 

If one turns on audit alarms for successful file accesses which are successful 

only through their use of BYPASS privilege, the original VMS Services for 

MS-DOS caused many alarms because it had a single server which carefully 

checked user-supplied passwords against SYSUAF but then proceeded to give 

access through the use of BYPASS. This is contrary to the spirit of a reference 

monitor, the concept which forms the cornerstone of current thinking about 

operating system security implementations. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


Shared Word Processing 

# 914.8 dated 25-FEB-1988 21:57 

From: Dale E. Coy (505) 667-3270 
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RE: 

“ I’m trying to prevent simultaneous access to the same 
data file (in this case WordPerfect documents). I would 
like multiple vaxmate users to be able to edit documents 
stored on a virtual disk—but obviously not at the same 
time. ” 

This is a tough one to get a handle on, since I don’t have WordPerfect. Can’t 
find a thing in documentation (of course), but here’s what I learned. PLEASE 
note the parts which are speculation below. 

FACT: If the file on the VAX is opened (I used a simple OPEN/APPEND 
XX filename), then PCFS claims it doesn’t exist, when asked to access it 
by anything I did. It displays the file name in the directory of the “virtual 
disk”, and will actually rename it if asked, but any other operation fails. 
CONCLUSION: If WordPerfect on the VAX “correctly” opens the file, and 
holds it, then no PC will be able to simultaneously use the file. SUGGESTED 
TEST: Try VMS WordPerfect on the same file, simultaneously by 2 users. 

SPECULATION: If PC Wordperfect “correctly” opens the file, and holds it 
open, then nothing else (PC or VMS) can simultaneously use the file. 

I don’t have any way to test any more than this. Perhaps someone will turn up 
with the answer. Note that (probably) the answer to PC Wordperfect probably 
will be the same regardless of the type of LAN - not specific to PCFS. 

Please let us all know if you confirm/refute the speculation, or find out anything 
else. 

DALE E. COY 

LOS ALAMOS NATIONAL LAB 
PO BOX 1663, MS J957 
LOS ALAMOS, NM 87545 
505-667-3270 


VAX and PC WordPerfect files 

# 914.9 dated 2-MAR-1988 23:27 

From: Bob Doherty 
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You should be aware that when you edit (and save) a WP file with VAX WP, 
the file is changed into a FB 512 byte record file. PC WP will in fact open 
that file, and will allow you to edit it, but it will not allow you to save it, since 
PCFS will only update stream files. You must save the edited file under another 
name. 

The problem is with PCFS and not with WP. I do not know whether this 
same situation obtains if you allow multiple file versions when you set up the 
server. 

Robert Doherty 
US DEPT of AGRICULTURE 
NUTRITION INSTITUTE 
B.161, R.102, BARC-EAST 
BELTSVILLE MD 20785 
(301 )-344-2147 


Incomplete tape I/O hangs cluster??? 

HSC 350 

# 918.2 dated 4-MAR-1988 00:51 
From: Don Hamparian - BATTELLE 

Definitely go to HSC V350. Big improvements in the tape subsystem. 


Don Hamparian 
Battelle Memorial Institute 
Room 11-6013 
505 King Ave 
Columbus OH 43202 
614-424-5086 


My kingdom for a password... 

Antecedent IO(s) published in: Pageswapper Volume 9 Number 9 (April, 1988) 


How about using DECnet?? 

# 920.3 dated 29-FEB-1988 05:38 

From: Rytis T. Balciunas 
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If all you want to do is verify that the user printed on the document is the 
“correct” user, why not just use the DECnet facility to do the checking for 
you?? 

Have the user enter in his/her password (no echo, of course), then do something 
like DIRECTORY ’’node’"username password":: 

Success means the user is who it should be, failure means no go. Of course, the 

obvious loophole is if the user hands out his/her password to someone else. 

RYTIS T. BALCIUNAS 

CALGON CARBON CORPORATION 

PO BOX 717 

PITTSBURGH PA 15230-0717 
(412)787-6784 


_ Flow control on DECservers _ 

# 921.0 dated 1-MAR-1988 12:16 

From: Larry A. Cannell 

We have several DECserver 200s which are connected to modems used for 

dialup. Is it really necessary to have flow control set on the DECserver? Or 

will setting readsync/ttsync on the associated lta: terminal line suffice for 

anyone who needs flow control? 

Larry A. Cannell 
8649 Wayside, Apt. 8 
Brighton, Ml, 48116 
(313)322-7272 


I don’t think you should do that. 

# 921.1 dated 1-MAR-1988 17:02 

From: Brian Tillman, Smiths Industries. 


Note 921.0 Flow control on DECservers: 

“ We have several DECserver 200s which are connected 
to modems used for dialup. Is it really necessary to have 
flow control set on the DECserver? ” 
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I’d say so. It seems to me that since the server buffers all input intended for a 
single node between two pulses of the service circuit timer into a single packet 
(or more if the input is large and won’t fit in one), at high terminal-server data 
rates, the server may want to XOFF a terminal momentarily. 

Besides, why would you WANT to turn it off? By default, XON-XOFF flow 

control is enabled and you have to do extra work to disable it. Besides, if 

you disable flow control, the server sends a message to the service telling it to 

disable flow control as well (at least that’s what the server manual says). 

Brian Tillman 
Lear Siegler, Inc. 

4141 Eastern Ave. MSI21 
Grand Rapids, Ml 49518-8727 
(616)241-8425 


I would use RTS/CTS if possible 

# 921.2 dated 1-MAR-1988 22:22 

From: Harry Herman 

We are using U.S. Robotics and Microcom modems with error correction, and 
I was never able to get the modems to work reliably with the terminal server’s 
default of XON flow control. If I started typing a large file and tried to use 
the A S/ A Q, or hold screen keys, the modems would start dropping characters 
and lines (I do like to see what I am typing, and can’t quite read at 19,200 
over the phone lines yet!) This may be due to the DECserver 200 software 
we have being the original base level with the XON/XOFF bug. This may 
also have been compounded because the modems were originally configured to 
send XON/XOFFs to the DECserver if the DECserver was sending too fast. It 
seemed like the listings could go a lot farther before there was noticeable errors 
if I did not use the hold screen key, than it would if I actually used the hold 
screen key so I could read what I was typing. 

I was able to get around the problem recently by switching the modems and the 
terminal server lines to use CTS/RTS flow control instead of XON/XOFF flow 
control. For the last two weeks, I have never noticed a dropped character in 
any listings I have done to my terminal. 

Harry Herman 
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Corpane Industries 
10100 Bluegrass Parkway 
Louisville, KY 40299 
(502) 491-4433 


Can a 2400 baud modem beat up a DECserver 

# 921.3 dated 2-MAR-1988 13:53 


From: Larry A. Cannell 


RE: 

“ Besides, why would you WANT to turn it off? ” 

Turning flow control off makes it easier to do binary file transfers with protocols 
other than Kermit(ie. Xmodem/Ymodem etc.) 

These modems are coming in at most at 2400 baud. Is it possible to overload 

a server within a circuit timer tic? If that was the case couldn’t you just lower 

the circuit timer? 

Larry A. Cannell 
8649 Wayside, Apt. 8 
Brighton, Ml, 48116 
(313)322-7272 


To handle lots of data 

# 921.4 dated 3-MAR-1988 13:32 

From: Seton Droppers, PBS, (703)739-5100 
Off the wall, but... 

If your terminal server had to fill more than one packet to transfer all the data 
from the TERMINAL SERVER to the “host” then it will want to X-OFF the 
incoming data. As I remember, the terminal server can send data from more 
than one session or connection to the host in a single packet, as it is set up to 
pack characters from all sessions connected to a single host in as few packets 
as possible. 
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Seton 

Seton R. Droppers 
Public Broadcasting Service 
1320 Braddock Place 
Alexandria, VA 22314 
(703)739-5100 


hard to overload a server 

# 921.5 dated 7-MAR-1988 19:58 


From: George Merriman CCA/NY 


RE: 

“ Is it possible to overload a server within a circuit timer 
tic? ” 

I have used terminal servers to monitor simplex news wire circuits with no flow 

control at speeds to 9600 BPS. Even with all channels of the server monitoring 

these channels, which almost never stop sending, I have not seen any evidence 

of server overflow. In fact, they seem to be much more efficient at this type of 

work than a silo-type multiplexor (DHV, DZV). 

George Merriman 
Cambridge Computer Associates 
56 Beaver Street 3rd Floor 
New York NY 10004 
212-425-5830 


Need help choosing right DBMS 

# 922.0 dated 2-MAR-1988 09:46 

From: Mark N. Katz 

We are undergoing a DBMS evaluation. The goal is to pick the best DBMS for 
our VAX application, which will be a large, complex database, in a transaction¬ 
processing environment. We have a few years experience with VAX DBMS but 
don’t consider ourselves all that knowledgeable, especially in areas related to 
performance. 
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We would like to get in touch with a company that is using VAX DBMS 
or Rdb in a large, complex production environment. We would like to hear 
about experiences, good or bad. Also would like to hear about studies done 
comparing DEC database products with 3rd party stuff. 

I think that there have been a lot of people asking these questions lately but not 
too many answers have appeared. 


Mark N. Katz 

GTE Government Systems 
100 First Ave. MS:1240 
Waltham MA 02154 


# 922.1 dated 2-MAR-1988 20:48 

From: Bill Mayhew 

Since you mentioned “transaction processing”, you should look into Software 
AG (of North America, SAGNA)’s AD ABAS product family, originally 
developed (and semi-famous) on Big Blue mainframes. They’ve been on 
VAXen for a year or more now and are making a fairly hefty push into the 
VAX area. 

I don’t know a lot about the product yet (I’m looking at it, myself), but they 
are running VAX-oriented seminars in various cities around the country in the 
next month or so. I have a friend who uses it in an IBM environment who is 
very high on it. One of SAGNA’s major claims is strength in the transaction 
processing area. 

The Boston seminar is on 3/22 and requires pre-registration. The company is at 
11800 Sunrise Valley Drive, Reston VA 22091, 703-860-5050, and a guy named 
Mike Schowalter is “Director of Digital Programs.” 

This is not an endorsement, advertisement, or anything else for this product. It 
may be a complete crock of_for all I know at this point. 
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I have designed, implemented and supported a relational DBMS myself that 
has been evolving over a number of years, so I hope to be able to ask them 
some intelligent questions. My particular interest is in distributed databases and 
transaction processing. Given enough time I hope to examine the other leading 
candidates, including Rdb, as well. 


Bill Mayhew 

Village Systems Workshop Inc 
PO Box 642 
Natick MA 01760 
617-237-0238 


System/Security Managers beware of ADABAS 

# 922.2 dated 3-MAR-1988 12:47 

From: Larry Kilgallen 

My direct discussions with Software AG are a year and a half old, but I believe 
their attitude has not changed in the interim. 

I believe the overall problem stems from the Software AG mind-set that if a 
VAX is running ADABAS then that is all it will be used for. The result is a 
fuzzing of the line between system management and database administration, 
to the detriment of security. Database vendors often have such an egocentric 
attitude, but at the time I talked to them, Software AG was intractable. I have 
seen such an attitude in the past on the part of some DEC database folks, but 
exposure to DECUS has beaten them into submission (who? me? unkind?) 
and I think DEC databases today provide good capability for separation of 
responsibilities. 

VAX ADABAS came to the client site in question because they wanted a 
common development environment for their VMS, VM and MVS machines. 

It is definitely a port from IBM-land, which also affects performance 
considerations, but I will constrain these remarks to security. 

The first aspect of ADABAS to make one grit one’s teeth was the failure to 
use VMSINSTAL. To this day (I just checked with someone else) at least 
some of the optional products Software AG puts on top of ADABAS have an 
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involved series of manual procedures combined with manually-executed DCL 
command procedures for installations. I have been told their (relatively) new 
“NETWORK” product has installation deficiencies in that “the documentation 
is wrong, especially for clusters”. 

Back to the base product though. Software AG insists that the database 
administrator must have xxx_IO privilege (I forget whether it is physical 
or logical, but it hardly matters). The stated reason is that in order to 
be compatible with their IBM version they do 10 based on cylinder and 
track rather than virtual block numbers. The code they provide makes these 
privileged calls in order to be able to reason in terms of cylinders and tracks. 
The master file which contains all the data for various databases must be 
aligned on a cylinder (or track, I forget) boundary. I argued in vain that if the 
file were created on that boundary then actual access to in could be on the basis 
of virtual block numbers since mathematical conversions could be used to find 
a new even boundary based on the knowledge of the disk geometry and the fact 
that the file (contiguous) started on an even boundary. No soap. 

Another example of their unfamiliarity with the VMS environment is that they 
take 0PER5 and presume it is for the use of the database administrator. No 
asking the installer what the site policy is, they just do it. If you try to modify 
their DCL (thank goodness they don’t do it in a compiled image) you find it a 
maze of twisty passages looking all alike. 

If you really want a stand-alone machine to do database and are planning on 
the system/security manager and the database administrator being the same, 
ADABAS may be acceptable. But if you want some degree of separation of 
duties (and if I were your stockholder I would hope you would), Software AG 
has a lot to leam. 

Larry Kilgallen 

Box 81, MIT Station 

Cambridge, MA 02139-0901 


Try FOCUS - Information Builders 

# 922.3 dated 4-MAR-1988 06:17 

From: Rytis T. Balciunas 
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Another product to consider is FOCUS by Information Builders. Its database 
portion is a little flukey on VMS, but from what I’ve seen, they’ve come a 
LONG way since the release we bought in 1986... The newest version comes 
with all kinds of goodies (expert systems, file sharing on PCs, etc.) It is 
pricey... We use it mostly for reporting from RMS files. 

I also agree with Larry’s comments on ADABAS - we saw the same problems 

when we were looking for a reporting/database package... Call me at (412)787- 

6784 if you want to ask details about FOCUS.... 

RYTIS T. BALCIUNAS 

CALGON CARBON CORPORATION 

PO BOX 717 

PITTSBURGH PA 15230-0717 
(412)787-6784 


Do you require DSRI-compliance? 

# 922.4 dated 4-MAR-1988 08:35 


From: MARK SHAFFER 

I’m more or less in the same boat as .0. I’ve spoken with reps of at least two 
dozen companies providing relational data base products for DEC VAX/VMS 
in the past several months. One question you might ask which may eliminate 
a good many (assuming it’s a requirement in your case as in mine): “Are 
your products DSRI- compliant?” If both the underlying database guts and 
the application-development toolkit stuff are DSRI-compliant, it means you’ll 
be able to mix and match with other DSRI-compliant products present and 
presumably future (like Rdb). This sounds like a good idea to me; otherwise 
one is tied to a proprietary, vendor-specific architecture. So far I’ve encountered 
about a half-dozen or so third parties who claim DSRI-compliance; the rest all 
say things like “planned for 3rd quarter 1988” or “what’s DSRI?”. 

MARK SHAFFER 

INFORMATION CONTROL TECHNOLOGIES.INC. 

17 POLLY DRUMMOND PROF. BLDG. 

SUITE 105 
NEWARK, DE 19711 
302-366-8211 

ADD^EYWOR^KWDj^TjDOirr)^^^^^^^^^^^^^ 

Remember, DSRI implies relational... 
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# 922.5 dated 4-MAR-1988 09:43 

From: Larry Kilgallen 

Although I think the DSRI-compliant criterion is a good one for relational 
products, it may be that the problem originally expressed in .0 would be better 
served by an implementation which is not relational. The DEC party line has 
typically been that high-contention transaction processing with multiple updaters 
is better done with DBMS (Codasyl) than Rdb (Relational). They go further 
to say that even with DBMS, multiple update performance is better filtering it 
through ACMS (as unnatural as that may seem to those of us from the VMS 
timesharing world). 

Now the vendors of INGRES and ORACLE will tell you that their relational 
products are faster than Rdb and as fast as any Codasyl implementation. Since 
they don’t have a Codasyl implementation to sell, they have a natural interest 
in touting the superiority of the relational approach. Most of the articles I have 
read about the superiority of relational databases, however, have dealt with 
ease-of-use rather than performance. What some VAX sites do is use DBMS 
for transaction processing and perform a nightly extraction into an Rdb database 
for ad-hoc query. Such an approach would presumably work with some other 
vendor’s relational database as well. 

To give another example of a “different” database, there is BASIS, which 

is optimized for text retrievals. That is a database which is not Network 

(Codasyl), Relational, or hierarchical (ancient IBM) in nature, but does one type 

of work better than the “standard” approaches according to the mmor mill. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


# 922.6 dated 4-MAR-1988 17:05 

From: Bill Mayhew 
Re: .2 

Thanks, Larry, you’ve given me a bunch of good stuff to prod the AD ABAS 
people about. 
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You’re not the only one with such a list of non-VMS-like attributes, by the way, 
though I think yours are all different from the other list I’ve seen (and hope I 
can find again...!) 

Re: .4 

A good argument can be made that DSRI is, itself, a proprietary, vendor-specific 
architecture... it just happens to be associated with our hardware vendor, which 
is just fine. But I haven’t detected a groundswell of support for DSRI in the 
industry, so your (and my!) hopes for a bevy of DSRI-compliant products to 
mix and match may be in vain. Then you have to raise the question about 
how DSRI relates to a multiple-hardware-vendor world; I haven’t studied DSRI 
enough myself, nor (more importantly) Digital’s plans for it, to have an opinion 
on that one, and would be interested to hear yours! 


Bill Mayhew 

Village Systems Workshop Inc 
PO Box 642 
Natick MA 01760 
617-237-0238 


Some Databases do and some don’t... 

# 922.7 dated 5-MAR-1988 11:16 

From: GREG P. SCHULZ 

Keep in mind that some applications are not suited for RELATIONAL databases 
while others are. How many reservation type applications do you know of that 
are running with relational databases. Another thing to keep in mind when 
looking at products and benchmarks, is that some products perform better under 
different circumstances. For example some databases perform better on mass 
deletes while others choke. But the one that chokes may have faster single 
transaction performance and better end user tools. 

Good luck with your search... 

P.S. We currently have INGRES, RDB, and FOCUS on the shelf. 
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Greg Schulz 

GREG P. SCHULZ 

BURLINGTON NORTHERN RR 

ISS LOC 3 

176 E 5TH STT 

ST. PAUL, MN 55164 

612 298-7344 


Some areas to look out for 

# 922.8 dated 5-MAR-1988 21:33 

From: Alan B. Hunt 

I agree with the others that the application will determine the best type of 
database product (relational vs. CODASYL). If you are looking at a Cluster 
implementation, I would say beware of Oracle since in clusters they do their 
locking on disk (under V5). I don’t know of any plans to change it. 

I would investigate any product very very carefully if you planning to use it in 
a cluster. NON-DEC shops often don’t understand clusters. Another area we 
found weaknesses in was whether the database could make use of VMS based 
security features (identifiers, usernames, UIC’s, etc). 

ALAN B. HUNT 
26803 BERG RD. #301 
SOUTHFIELD, Ml 48034 


Yes, beware of "master process" implementations 

# 922.9 dated 6-MAR-1988 08:41 

From: Larry Kilgallen 

Even if you are not planning on running your database in a cluster, your plans 
might change in the future, so it is best to consider cluster behaviour from the 
start. 

The two DEC databases (3, if you count RMS) perform disk IO directly from 
the user process with no intermediate master process. Likewise they use the 
distributed lock manager to detect contention across the cluster. I know of one 
other database (System 1032) which does IO directly from the user process. 

In that case they do intra-node locking with a global section and inter-node 
locking with the distributed lock manager. The point is that these databases 
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do not shuffle data across to a master process for disk I/O (which would incur 
process context switch overhead as well as transfer overhead) and they are also 
well-suited to keep on running when a node crashes (at least if you happen to 
be on one of the surviving nodes of the cluster). 

The typical approach for databases ported from IBM machines (where there is 
nothing comparable to a VAXcluster) is to establish a central process which 
will handle all the disk 10. In defending that approach, vendors will say that 
a central process is more efficient than the distributed lock manager. With 
the adjustable locking granularity algorithms DEC uses in their databases I 
think that view is questionable (although it is always possible to construct 
pathological examples). I know the implementation of data transfer to a central 
process on another node in a cluster is inefficient, and I doubt that any of these 
databases with a central process has the ability to have some users keep on 
running if the node with the central process crashes. (The last point merely 
increases an individual user’s exposure from 1/n to 2/n, but it does lead to 
situations where, from a system management standpoint, 100% of the users are 
mad, vs 1/n of the users.) 

So what does System 1032 have in common with DEC databases? They were 
all written with VAX/VMS in mind! 

Larry Kilgallen 

Box 81, MIT Station 

Cambridge, MA 02139-0901 


Thanks 

# 922.10 dated 8-MAR-1988 18:51 

From: Mark N. Katz 

Thanks to everyone for some great information and pointers to other notes with 
more good info but.. 

Is there anyone out there who is TODAY running a large VAX DBMS or Rdb 
application out there. We have been running DBMS and we haven’t been 
happy with performance. Over the last few weeks, with some help from DBMS 
development, we have found some problem areas - but we still don’t know 
whether we are running DBMS at its limit or misusing it into the ground. 
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The new project we are embarking on has similar, maybe higher, performance 
requirements and we need to make some decisions pretty soon. Anybody out 
there willing to give us their experience on transactions per second, nature of 
transactions, machine environment, other stuff happening on machine at same 
time, etc. 

I realize that this is a lot of stuff to type in to a Notes system, so a phone call 
might be quicker for some of you. I will try to update this note with any data 
received that way if it makes your life easier - or keep it private if you don’t 
want it spread around. 

You can reach me at (617)466-3437 or call Elaine Ng at (617)466-3607 

Mark Katz (and thanks again for all the help so far) 

Mark N. Katz 

GTE Government Systems 
100 First Ave. MS:1240 
Waltham MA 02154 


The limitations of this discussion medium 
# 922.11 dated 8-MAR-1988 20:30 


From: Larry Kilgallen 

Lest there be any fear that people are not making heavy use of these products, 
let me say that I know of sites which are doing so. The problem is that they 
have not chosen to participate in these (or other) DECUS discussions. Whether 
by intent or by accident, we unfortunately have to respect their self-imposed 
isolation. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


Well, I tried 

# 922.12 dated 10-MAR-1988 11:27 


From: Mark N. Katz 
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Of course. Just trying to drag some people out of the woodwork if they’re 
there. Wish there was a similar service offered by the DMS SIG or some kind 
member thereof. 

Mark N. Katz 

GTE Government Systems 
100 First Ave. MS:1240 
Waltham MA 02154 


Some good data base discussion starting on DECUServe 

# 922.13 dated 10-MAR-1988 13:37 


From: Bob Hassinger 


Bob Hassinger 

Liberty Mutual Research Center 
71 Frankland Road 
Hopkinton, MA 01748 
617-435-9061 


Keep this discussion going... 

# 922.14 dated 10-MAR-1988 18:46 

From: GREG P. SCHULZ 

Mark, we are in the process of implementing a rather large (Gigabytes 
shadowed) database application using either RDB or INGRES or both. We 
to are interested in interacting with others who are using or developing large 
database applications. 


GREG P. SCHULZ 

BURLINGTON NORTHERN RR 

ISS LOC 3 

176 E 5TH STT 

ST. PAUL, MN 55164 

612 298-7344 


A compliment, for a change 

# 927.0 dated 5-MAR-1988 22:28 
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From: Dale E. Coy (505) 667-3270 

We’ve beat up on DEC fairly heavily in the support area, so it’s appropriate to 
recognize the good stuff, too. 

The Terminal Server area in DSIN has a large number of helpful hints, example 
programs, etc., and seems to get updated and added to frequently. Whoever is 
doing that deserves a big hand for providing an example of good support. 

DALE E. COY 

LOS ALAMOS NATIONAL LAB 
PO BOX 1663, MS J957 
LOS ALAMOS, NM 87545 
505-667-3270 


Great job... 

# 927.1 dated 9-MAR-1988 21:59 
From: GREG P. SCHULZ 

It would be great if some of the other product groups followed the terminal 
server (NETWORK) group in the are of DSIN items. My compliments to DSIN 
on the DS200 V2.0 index of articles. 

P.S. Thanks also to the SNA group for finally placing some very good 

information into DSIN... 

GREG P. SCHULZ 

BURLINGTON NORTHERN RR 

ISS LOC 3 

176 E 5TH STT 

ST. PAUL, MN 55164 

612 298-7344 


# 927.2 dated 10-MAR-1988 11:06 

From: Bill Mayhew 

I agree, wholeheartedly. I also note that an index to the terminal server articles, 
with supporting info (like the fact that the terminal server needs to be on your 
“supported product list” for you to access them), has popped up among the 
VMS articles. 

The terminal server group is doing something right; let’s encourage the other 
groups to follow their example. 
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Bill Mayhew 

Village Systems Workshop Inc 


PO Box 642 
Natick MA 01760 
617-237-0238 


V4.7 TTDRIVER Speed Problem 


# 929.0 dated 8-MAR-1988 08:01 


From: Bob Doherty 

Has anyone else noticed any anomalies with the v4.7 TT driver? 

We regularly downline load files from our VAX to a MAC ][ over a 19.2 kb 
serial line(hardwired DMF32 port) and with the 4.6 driver using VMODEM 
from the VAXNet distribution we would normally get transmission speeds of 
3200 to 4200 baud with the 128 byte XMODEM packets. When we upgraded 
to 4.7, this rate went down to ca. 1400 baud. When we restore the 4.6 driver, 
the problem goes away. 

According to the release notes(I haven’t checked the fiche yet), the change in 

TTDRIVER was to cure problems with multiple sessions with VWS. Is this 

related to that change, or has something else been introduced? 

Robert Doherty 
US DEPT of AGRICULTURE 
NUTRITION INSTITUTE 
B.161, R.102, BARC-EAST 
BELTSVILLE MD 20785 
(301 )-344-2147 


Something changed, alright! 

# 929.1 dated 9-MAR-1988 14:54 
From: Stuart Renes, DFWLug Chair 

I too have had problems with the VMS V4.7 TTDRIVER. My particular 
problem is that my user-written pseudo-terminal driver now returns data 
overrun errors. This driver had been working for several years and still works 
on small, presumably slower VAXes such as a VAXstation 2000 and a VAX 
11/725 running V4.7 but not on an 8530. 
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I’m waiting (patiently?) for the 4.7 fiche so I can find out just what DEC did to 
the driver. 

By the way, they claimed to fix some VWS windowing problems with the new 
driver code BUT my VAXstation 2000 has DEVELOPED problems with the 
new driver. 

Stuart Renes 

AT&T Technologies, Inc. 

Mail Stop: 2793 
3000 Skyline Dr. 

Mesquite, TX 75149 
(214) 288-2286 


Don’t be patient! 

# 929.2 dated 9-MAR-1988 16:46 


From: Larry Kilgallen 


RE: 

“ I’m waiting (patiently?) for the 4.7 fiche so I can find 
out just what DEC did to the driver. ” 

The V4.7 microfiche arrived in Boston some time ago. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


# 929.3 dated 9-MAR-1988 22:06 

From: GREG P. SCHULZ 

We to are still waiting for fiche in St. Paul. We have noticed some abnormal 
behaviors lately on terminal server ports that may or may not be related to the 
TTDRIVER. In one case a system administrator reported a data under-run error. 
We have one system that is connected to our main ethemet via reverse lat (until 
translan is installed) via DECmux II and DS200. Lately we have been noticing 
degradation as time and usage increase to the point where terminals lock up. Is 
it the TTDRIVER or could it be time to look at ETDRIVER.EXE again. 

GREG P. SCHULZ 
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BURLINGTON NORTHERN RR 

ISS LOC 3 

176 E 5TH STT 

ST. PAUL, MN 55164 

612 298-7344 


Kermit weirdness 

# 929.4 dated 10-MAR-1988 09:19 

From: G. Del Merritt 

I too have noticed a problem with PC transfers when using Kermit. I first saw 
it when the PC was connected to a TCP/IP terminal server. Then I switched it 
over to a direct connect to my DMZ32, but saw no change. The Kermit being 
used on the PC end was the PROCOMM version. For lack of time, I haven’t 
looked much further. A side note, though, is that I see no problem or difference 
down/uploading to the Pageswapper at 1200 baud using my VAX Kermit, so I 
was figuring it was the PC at fault... 

G. Del Merritt 
55 Walkers Brook Drive 
Reading, MA 01867 


Weird here, too 

# 929.5 dated 11-MAR-1988 05:04 

From: Terry Kennedy 

I’ve had some oddities since installing 4.7, too. I have terminals (VT102’s) 
on a data switch at 4800 baud. The data switch connects to ABLE VMZ32’s, 
which have been quite re- liable. Now, all of a sudden, I have things happening 
like SHOW DEVICE TXA0: reporting 417 errors on the terminal. Yet at other 
times things are just fine. I swapped the VMZ32’s without effect. I think I’m 
going to try the 4.6 TTDRIVER next. 

Terence M. Kennedy 
St. Peter’s College 
Department of Computer Science 
2641 Kennedy Boulevard 
Jersey City, NJ 07306 
(201) 435-1890 


Good Idea. 

# 929.6 dated 11-MAR-1988 09:07 
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From: Stuart Renes, DFWLug Chair 

I think I too will re-install the VMS 4.6 TTDRIVER on my VAXstation 2000 
to see if things reverse themselves. 

Does anyone who HAS the 4.7 fiche know exactly what was changed in the 
terminal class driver? (I just KNOW you all have scads of time available to 
scan the microfiche!! :-) 


Stuart Renes 
AT&T Technologies, Inc. 
Mail Stop: 2793 
3000 Skyline Dr. 
Mesquite, TX 75149 
(214) 288-2286 


Cures our problem 
# 929.7 dated 11-MAR-1988 19:07 


From: Bob Doherty 


RE: 

“ I think I too will re-install the VMS 4.6 TTDRIVER on 
my VaxStation 2000 to see if things reverse themselves. ” 

I reinstalled the 4.6 driver and the bizarre speeds went away. So, at least for 
the problem which I originally reported, the problem is in the TTDRIVER. 

Robert Doherty 
US DEPT of AGRICULTURE 
NUTRITION INSTITUTE 
B.161, R.102, BARC-EAST 
BELTSVILLE MD 20785 
(301)-344-2147 


The fiche are biting 

# 929.8 dated 14-MAR-1988 04:06 


From: Terry Kennedy 
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RE: 

“ Does anyone who HAS the 4.7 fiche know exactly what 
was changed in the terminal class driver? ” 

Well, I looked... The problem is that: 

• The ’new image’ is a patched ’old image’ - they are both Version ’X-4’ 

• Patches are not reflected in the fiche (usually) 

• Comments in the fiche header do not indicate changes of the “While I’m 
here, this looks wrong so I’ll change it” variety. These are usually what kill 
you... 


Terence M. Kennedy 
St. Peter’s College 
Department of Computer Science 
2641 Kennedy Boulevard 
Jersey City, NJ 07306 
(201) 435-1890 


Can’t fix something if you don’t know! 

# 929.9 dated 16-MAR-1988 21:27 

From: Mark Schell (919) 773-7040 

If this is as bad a problem as it sounds, PLEASE SPR IT!!! 
Mark Schell 

DIGITAL EQUIPMENT CORPORATION 
8025 NORTH POINT BLVD 
SUITE 100 WEST 
WINSTON SALEM NC 27106 


It *has* been... 

# 929.10 dated 16-MAR-1988 23:14 


From: Terry Kennedy 
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I have SPR’d this as an addendum to my 3 other SPR’s, all dating back to 
V4.4: 

• If a /MODEM/DIALUP port is XOFF’d, the next caller must type a A Q at 
the same baud rate to unhang the port. 

• There is no typeahead at the Username: prompt - you have to wait until the 
welcome message is done - so lengthening the welcome message will break 
automated login scripts 

• On ports set /EIGHTBIT, characters with the parity bit set are treated as 
multinational in usernames and passwords. 

DEC has not seen fit to respond to any of these. When contacted, the person I 

spoke to said there is a backlog of about 2 years from report date to Dispatch 

publication, let alone fixing it. Furthermore, I was told that these things are 

only fixed when VMS isn’t actively working on a new release (about a 2-week 

period every 6 months). 

Terence M. Kennedy 
St. Peter’s College 
Department of Computer Science 
2641 Kennedy Boulevard 
Jersey City, NJ 07306 
(201) 435-1890 


VMS 4.7 BACKUP BUG??? 


# 937.0 dated 10-MAR-1988 22:57 
From: HANK VANDER WAAL 

I WAS TOLD BY SOMEONE (OR READ SOME WHERE) THAT THERE 
IS A BUG IN 4.7 BACKUP WHERE THE FIRST TAPE WILL FINISH 
AND REWIND AND INSTEAD OF DISMOUNTING IT THE SYSTEM 
WILL START WRITING OVER IT ONE WHAT IT THINKS IS THE 2ND 
VOLUME!!!! IF SO IS IT FOR ONE TYPE OF DRIVE??? 
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HANK VANDER WAAL 
CDS 

4714 FEN WOOD SW 
GRAND RAPIDS Ml 49504 
6164530630 

# 937.1 dated 11-MAR-1988 07:31 

From: Larry Kilgallen 

I have heard this bug is specific to the Micro VAX/VAXstation 2000. 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


I called C. Springs 

# 937.2 dated 14-MAR-1988 11:38 

From: George Bone 

I called Colorado Springs about it, and the representative I talked to told me 
that they had not received any reports on a problem such as this. 

The mmour I heard was from a column in a widely read Digital products 
specific newspaper, and was actually in a “rumours” type of column. It 
could be that the person who experienced the problem was suffering from 
rectal-cranial inversion (I know I often suffer from that). 

George Bone 

Code 2301.2 Mail Stop T-11 
Mare Island Naval Shipyard 
Vallejo, CA 94592-5100 
(707)646-2531 

# 937.3 dated 16-MAR-1988 10:52 

From: CHUCK MCMICHAEL 

Using the V4.7 on-line backup with an 11/750 and TU80, I’ve had no such 
trouble. 

CHUCK MCMICHAEL 
PITTSBURGH CORNING CORP 
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800 PRESQUE ISLE DR 
PITTSBURGH PA 15239 
412-327-6100 


I’ve seen it - and so has DEC! 

# 937.4 dated 16-MAR-1988 20:53 

From: Bob McCormick 
And here’s the real POOP! 

I’ve seen it!... On a Micro VAX 2000 with the SCSI TK50Z-FA tape drive, I 
was backing up an RD54 to the tape - and it completely filled the tape (I didn’t 
expect it to). 

This thing ran unattended (for quite some time). Oddly enough, when I came 
back I found that all by its lonesome it had rewound the tape and -yes Virginia- 
decided to play real two on top of one! 

Well, I ignored that problem (I wasn’t sitting there watching it; I think it sat for 
over a weekend)... 

But... I was talking to someone last week (Friday sounds specific) regarding 
another backup problem I was having and they mentioned (without anything 
from me to prod it) the backup rewinding the tape, and if you didn’t mount 
another tape (and respond) in a certain amount of time, the last tape would be 
automatically mounted and written over. In case you’re wondering: Micro VMS 
V4.6 

Is it a bug, or a feature? Is it unique to the SCSI driver - or all systems? 
What’s the timer value? Can it be changed? Ho Hum 


BOB MCCORMICK 
39 FORGE ST 
FEEDING HILLS MA 01030 


addendum to 937.4 
# 937.5 dated 16-MAR-1988 20:55 

From: Bob McCormick 


VAX-81 




PAGESWAPPER - May 1988 - Volume 9 Number 10 
INPUT/OUTPUT 


that someone was ’someone’ out at Colorado Customer Support 

BOB MCCORMICK 
39 FORGE ST 
FEEDING HILLS MA 01030 


Setting NET*.DAT to be WORLD READ 

# 942.0 dated 19-MAR-1988 07:34 

From: Larry Kilgallen 

A couple of sites in the Boston area have reported that the upgrade to VMS 
V4.6 and/or VMS V4.7 has unprotected NETUAF.DAT and other files matching 
the specification SYS$SYSTEM:NET*.DAT to be WORLD:RE. This is 
looser than specified in the Guide to VAX/VMS Security. These are not 
sites particularly susceptible to Chaos Computer Club attacks. 

Have others seen this, or have people at these sites been smoking funny 
cigarettes? 

Larry Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 


same thing here 

# 942.1 dated 19-MAR-1988 18:34 
From: George Merriman CCA/NY 

I can confirm that a client’s 4.7 LAVC has the world protection set as you note 

for files in sys$common:[sysexe]. The files in sys$sysroot:[sysexe] have no 

world access granted. I can’t say if this was true in 4.6. On a non-clustered 4.7 

system at the same site in New York City none of the NET*.DAT files have 

world access granted. 

George Merriman 
Cambridge Computer Associates 
56 Beaver Street 3rd Floor 
New York NY 10004 
212-425-5830 

Imagine my surprise... 
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# 942.2 dated 21-MAR-1988 20:06 


From: Saul Tannenbaum 

Having just looked at my system, NETUAF is world:re. I certainly didn’t do 

that myself. All the other net files seem protected correctly. This is on {VMS 

4.7, cluster common system disk. 

Saul Tannenbaum 
Tufts University 
HNRC 

711 Washington Str. 

Boston, MA 02111 
(617)556-3346 


Well, I’ll be! 

# 942.3 dated 22-MAR-1988 10:15 
From: Jonathan M. Prigot 

I just checked on our three DECnetted VAXen. NETUAF on ours (V4.6) does 
not grant WORLD anything. The other two (V4.6 and V4.7) both have W:RE. 
We overhauled our security a few months ago, so that is probably why ours is 
set properly. To the best of my knowledge, no similar thing has ever been done 
with the others. 

Jonathan M. Prigot 
W.R. Grace & Company 
55 Hayden Avenue 
Lexington, MA 02173 
617-861-6600 x2148 


50 - 50 

# 942.4 dated 22-MAR-1988 12:38 

From: G. Del Merritt 

My 4.7 standalone system has NETUAF unreadable by the world, but there are 

several NET*.DAT files that allow W:RWE. I know that I have done nothing to 

change any of the protections... 

G. Del Merritt 
55 Walkers Brook Drive 
Reading, MA 01867 


Choices abound 


VAX-83 





PAGESWAPPER - May 1988 - Volume 9 Number 10 
INPUT/OUTPUT 


# 942.5 dated 22-MAR-1988 17:21 

From: Kevin Angley 

On my cluster common system disk, NETUAF.DAT is not world-accessible. 

On a standalone Vaxstation II/GPX, NETUAF.DAT has w:re. This system was 
upgraded to 4.7 using a VMS kit, not a MicroVMS kit, by the way if that gives 
any clue. 


Kevin Angley 
3301 Terminal Drive 
Raleigh, NC 27604 
(919) 890-1416 
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Cincinnati Symposium Preview 

Thomas M. Byrne, Business Application SIG Marketing Coordinator 

With Uncle Sam’s help and cooperation, you should be receiving this month’s Newsletter in time to help 
you plan what to see and where to go during the Spring 1988 Symposium. 

In talking to those who were fortunate enough to attend the last Cincinnati Symposium, a few years ago, 
I hear the facilities are first rate. 

If the weather is poor, the Convention Center and the major Symposium hotels are all connected by an 
enclosed Skywalk. 

If the weather is good, and it should be great at this time of year, everything is within easy strolling 
distance. 

Friends in the "Queen City" tell me that this is their Bicentennial Year and they are pulling out all stops 
to make it a memorable one for residents and visitors. A check with your travel agent or the Convention 
Bureau should provide you with a host of special activities to take advantage of. 

The Business Application SIG is also going all out to provide you with the best Symposium program 
possible. We have scheduled 51 hours of sessions filled with more information than that breakfast cereal 
has raisins! 

Some of the highlights are 14 hours on managing your DP shop and/or Information Center, 6 hours on 
Transaction Processing, 9 hours on AI issues and Application Development Tools, plus the proverbial 
much, much more. 

In addition to the usual horde of Digital speakers, folks from companies like Cognos, Touch Technologies, 
and Clyde Digital Systems are scheduled to appear. 

We also have "real users", just like you! Folks from the U.S. Coast Guard, Corning Glass Works, and E & 
J Gallo Winery, to name a few, will be sharing with you problems and solutions, benefits and pit-falls of real 
world applications. 

Let’s not forget "Late Night with BA"! On Monday night, our very own refulgent Dan Esbensen will play 
the Caterpillar in an "Alice in Wonderland" journey through speaker interviews, wizardly magic acts, and 
good clean fun! This session was standing room only in Anaheim, so be sure to arrive before the curtain 
goes up on one of the most memorable sessions you’ll ever attend! 

Last, but definitely not least, stop in the Business Application Suite. 

The BA Suite may be the best place in town to stop in and spend a moment or two. You will have a chance 
to meet and talk with many of our speakers. You can also chat with the folks of BA and give them your 
ideas about what makes a Symposium worthwhile for you. 

We’ll see you in Cincinnati! 
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From the Editor 


Bob Hays 

KMS Fusion, Inc. 

3621 South State Road 
Ann Arbor, MI 48106 
(313) 769-8500 x 458 

This month the newsletter survey is being mulled over by 
DECUS leadership. A large number of surveys were returned, 
which is pleasing, and most of the surveys have what 1 consider 
very constructive ideas. More information will appear as I get 
it. 

The DECUS symposium is this month; I hope everyone in 
attendance has fun and gets all their questions answered. The 
symposia are THE place to ask developers from Digital 
Equipment about products, problems, and futures. I’ve 
attended two symposia and have always had my questions 
answered (not always as 1 would have preferred, but that’s not 
the issue). 


The GAPSIG Woods meeting is the weekend of March 26th and 
27th. A summary of the meeting should appear in the June 
newsletter (there is currently a two month lag between delivering 
a newsletter to the DECUS national office and having it 
published). 

This month, the NOTES session on GRAPHICS from the Fall 
Symposium are finally provided (sorry they didn’t get into last 
month’s issue - RLH). There’s also an article on desktop 
publishing from Henry Schneiker. 

Submissions are always welcome! Please send any tips, 
questions, articles or ideas to Bob Hays at the address at the left. 
As you can expect, l prefer electronic submissions which means 
tape (VMSBACKUP or RSX BRU) or on-line on DCS. However, 
if you cannot make a submission via electrons, use paper! I type 
mass quantities a couple of times a month and my fingers still 
work great! 


Graphics NOTES session 
DECUS Fall 1987 Symposium 


Note 2.2 Registrv 

VAXFAM: :MMCPHERSON 
13 lines 7-DEC-1987 11:26 


Note 2.3 Registry 

VAXFAM: :GMERR1TT 

11 lines 7-DEC-1987 15:15 


Hi everyone. I am: 

Mike McPherson 
Acting Chair, Graphics SIG 
A. H. Case Center for CAEM 
236 Engineering 

Michigan State University (Go State! Beat USC!) 

East Lansing, MI 48824 

517-353-9769 

Interests: Workstations 

Workstation Management 
GAPSIG Issues 


Note 2.6 Registry 

VAXFAM: :RGOLDSTEIN 
8 lines 8-DEC-1987 16:06 


Bob Goldstein 

Head of Automated Information Processing Systems 
Eye Research Institute of Retina Foundation 
20 Stamford St 
Boston, MA 02114 
(617) 742-3140 x404 


G. Del Merritt 
TASC 

55 Walkers Brook Dr. 

Reading, MA 01867 
(617)942-2000 

Interests: GKS 

Image Processing 
Image Understanding 

High quality animation (we have PIXAR #1) 
Fast rendering 


Note 2.5 Registry 

VAXFAM: :MHENDERSON 
10 lines 8-DEC-1987 08:50 

Matthew C. Henderson 

CAPS Network and Systems Manager 

Unisys Defense Systems 

600 Gemini Avenue, M.S. U06C 

Houston, Texas 77058-2775 

Interests: Graphics standards 
Workstations 

Graphical hardcopy devices 
User interface standards 


Note 2.4 Registry 

VAXFAM: :LCANNELL 
7 lines 7-DEC-1987 16:35 

Larry Cannell 

System Manager/Programmer 
Ford Motor Co 
21500 Oak wood Blvd 
Dearborn, MI 48121 

Interests: Finding out more about GKS. 


Note 3.0 Redirecting GKS output to a file 

VAXFAM: :LCANNELL 

10 lines 7-DEC-1987 16:34 

Is GKS capable of redirecting the output that would normally go 
the the hardcopy device(in this case a plotter) to a file? That file 
would then be spool to that device at some later time using a 
symbiont. I don’t mean a metafile, that won’t do be any good 
in this case. It has to be a file that can be simply copied or 
printed to the particular hardcopy unit. 
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Note 2.1 Registry 

VAXFAM: :JBLOOM 
12 line 7-DEC-1987 11:25 

John Bloom 

Senior Research Mathematician 
Chevron Oil Field Research Co. 

P.O.Box 446 

La Habra,Ca. 90633-0446 

I have been programming high performance graphics 
applications lor 7 years, and am trying to port some of the 
applications to a GPX under VMS. In order to efficiently 
provide the "plane-mask" feature, I am attempting to use DOPS 
under U1S. I would appreciate making contact with anyone 
with knowledge of DOPS, especially the bit-mask features. I 
cannot seem to gel the use mask flag to work. 


Note 2.7 Registry 

VAXFAM ::DSTONE 

20 lines 9-DEC-1987 13:13 

David M. Stone 
Svstem Man ager/ Program mer 
Shriners Burns Institute 
51 Blossom st. 

Boston MA 02114 
(617) 722-3000 x260 

Interests: Almost every aspect of programming a computer (It’s 
not just an adventure; it’s a job) 

I have several applications which I have put up on a GPX, 
including 3-d reconstructions. I need a small amount of help 
using DOPS, namely how does one use bitmaps for dashed 
lines?? The book isn't very clear on color bitmaps, and 
everything I’ve tried has failed. 

I also need a lot of help with synchronization problems and lack 
of good documentation. 

If anyone is looking for help in other areas (such as plain old 
UIS calls), I'd be glad to help (or at least trade horror stories). 


Note 2.8 Registry 

VAX FAM::J BLOOM 

16 lines 9-DEC-1987 14:36 

Yes, the DOPS documentation is poor when it gets to 
bitmap (especially multiplane bitmap) use. I am having trouble 
with bitmamasks, and also in figuring out where and how DEC 
stores its fonts (so that I can use them from DOPS.) 
Furthermore, it is very difficult to find anyone at DEC to 
answer a question. There was supposed to be one VMS 
graphics expert at DECUS, but he got sick and could’t come. 

If DEC is serious about attracting graphics users, they must 
realize that we want performance, and that we want to use all 
the features on a particular device. For now, that means 
DOPS. Waiting a year for X is too long. (In the computer 
graphics field, a year is forever.) Even with X, many of the 
features of the GPX chip wall be hidden (such as copying 
offscreen bitmaps with scaling: bit replication will have to be 
done on the host, and full-screen images transfered from client 
to server.) 


Note 3.1 Redirecting GKS output to a file 

VAXFAM: :BAXTELL 
10 lines 8-DEC-1987 12:02 

GKS is capable of redirecting hardcopy protocols. To do this, 
choose the workstation type as the type of device you wish to 
use, and define the connection id to be a VMS file specification. 
The output will then be directed to a file by the specification and 
the file may then be spooled to a graphics device. 

Brian Axtell 

Base Graphic Systems Group 
Digital 


Note 4.0 Higher Level Graphics Tools 

VAXFAM:: MODERATOR 
17 lines 8-DEC-1987 07:50 

There will be an informal session this afternoon (Tuesday) in the 
GAPS1G campground. The subject is "Higher Level 
GraphicTools" and the purpose is to give user's a chance to tell 
DEC what they require in a graphics toolkit to do their job. The 
topic comes up because many people think that packages like 
VAX GKS and VAX PHIGS provide tools that are at to low a 
level. For example, with VAX GKS and VAX PHIGS, functions 
are supplied for drawing lines, markers, text etc. No functions 
are provided to draw an axis for a graph, or a bar chart in one 
call, etc. 

If you want to have the advantages of a device independent 
package like VAX GKS or VAX PHIGS, but find them too 
"primitive", come to the GAPS1G campground at 4:00 today to 
tell DEC what you really need. 

Jim Flatten 

VAX GKS/VAX PHIGS Product Manager 


Note 5.0 RGL (RcGIS) Users Out There??? 

VAXFAM:: MODERATOR 
5 lines 8-DEC-1987 07:55 

I’d like to hear from anyone here that is an RGL (ReGIS Library 
user). What is keeping you from moving to GKS or PHIGS? 
How many of yoare there out there? How many would move if 
you could? 

Jim F. 


Note 5.1 RGL (ReGIS) Users Out There??? 

VAXFAM:.RHAYS 
6 lines 9-DEC-1987 12:23 

Yes, Jim, we use ReGIS a little at our site for various old (OLD) 
code. We just don’t have time to re-code all that good "stuff". If 
you can find a way to minimize rewriting, then I’m all for it. 

Bob Hays, KMS Fusion 


Note 5.4 RGL (ReGIS) Users Out There??? 

VAXFAM: :DBOLTHOUSE 
5 lines ll-DHC-1987 11:38 

When are DEC products (i.e., Datatrieve) going to move away 
from RGL? 

David L. Bolthouse 
Texas Instruments 
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Note 5.2 RGL (ReGIS) Users Out There??? 

VAXFAM: :JBURNET 
8 lines 10-DEC-1987 17:03 

>- If you can find a way to minimize rewriting, then I’m all 
for it. 

If you have a *lot* of code that uses RGL calls, you could of 
course write an "RGL emulator" library that would turn RGL 
calls into GKor PHIGS calls. This would only be worthwhile if 
you stand to lose a lot oftime by converting the code some other 
way, but you could of course donate the resulting RGL-to-GKS- 
or-PHIGS routines to the DECUS library and earn the eternal 
gratitude of the other 5 RGL users in the world. 


Note 5.3- RGL (ReGIS) Users Out There??? 

VAXFAM.: WWEISSBORN 
18 lines 10-DEC-1987 17:05 

I use it at my site but I think that I am the only one. The main 
reason I use it is because of speed (?) and simplicity. Let me 
explain. 

My company has a development license for a product called 
UN IRAS which supports GKS. But to do terminal io I only 
have drivers for Tek 41 xx and Tek 42xx terminals. Since I am 
but a lowly sys manager and programmer, I don’t get the really 
neat toys so I am "stuck" with a VT240. So I use REGIS, 
That what I mean about simplicity. It is easier for me to crank 
out my little plots with REGIS that trying to have to wrestle a 
TEk terminal away from an engineer. 

As far as speed is concerned, I mean speed of coding, not 
necessarily speed of execution. Again, our "wonderful" 
UNIRAS, hasa lot of bugs when it comes to terminal i/o, so it 
is usually faster for me to use REGIS and to try and debug 
UNIRAS’s code. 

Hope that helps 


Note 7.0 Problems, problems with VAX GKS V3 

VAXFAM ::FNAGY 
20 lines 9-DEC-1987 09:36 

Configuration is VMS V4.6, VAX GKS 3.0 and (where 
appropriate) VWS V3.2. 

#\: With a VT330, using a pick input device and a string input 
device alternately - but both devices are using EVENT mode - 
the string input buffer oftern receives cursor update 
information. 

#2: With a VAXStation, a call to GKSSINQ WS XFORM 
returns x- and y-maxima which are greater than the size of the 
screen if the open viewport is in the upper right hand corner. 

#3: With a VAXStation, the echo area for a pick device 
apprently needs to be the entier screen in order to pick 
segments from an entire viewport. Seems that the transforms 
may be wrong... 

#4: When calling GKS$AWAIT EVENT event at AST level, if a 
GKSSCREATE SEG or GKSSDELETE SEG has been 
interrupted by the delivery of the AST, an error condition exists 
and the program crashes. 

(Problems passed on for Brian Kramper, Fermilab (312) 
840-3927] 


Note 7.1 Problems, problems with VAX GKS V3 

VAXFAM: :JFLATTEN 
5 lines 9-DEC-1987 11:27 

I have extracted your note and will pass it on to the GKS 
development group. Thanks for your input. 

J. Flatten 

VAX GKS Product Manager 


Note 6.0 Any UNIRAS users out there 

VAXFAM: WWEISSBORN 
10 lines 8-DEC-1987 14:41 

I am interested in hearing from anyone else out there that is 
using UNIRAS. Do you have problems with: 

1) Performance - taking a loooong time to create files 

2) Buggy releases 

3) Poor documentation. 

We seem to suffer from all of the above and would like to know 
if it is just us or what? 


Note 6.1 Any UNIRAS users out there 

VAXFAM: :J BLOOM 
17 lines 9-DEC-1987 14:11 

Our initial installation of UNIRAS was quite buggy, but we 
refused to pay for it until it worked, which did wonders. Some 
operations are slow vs using customized code, but that is the 
problem with using a generic system. UNIRAS seems no slower 
than other general purpose systems, and contains a lot of 
functionality. 

We find UNIRAS extremely useful for scientists and engineers 
who need to draw something, but don’t want to become graphics 
experts. 

We do not find UNIRAS usefull for writing production systems 
that will be used over and over, especially not for interactive 
ones. However, we have found no other suitable general purpose 
system, and have ended up using home grown "standards". 

The hope is that "X" will remedy this situation by providing a 
fast standard that understands raster devices. Wait two years, 
and then we’ll know. 


Note 8.0 UIS-Tool-Box on top of DECwindows 

VAXFAM ::DROBERTS 
21 lines ll-DEC-1987 11:33 

I want to know if it is wrong to think that a "UIS-ToolBox" 
could be put on-top of DECwindows. I’ve heard that the X- 
window server is dumb, and the real programming is done by 
the client software. 

Well then, couldn’t a tool box be developed by DEC which uses 
the standard UIS calls, and send them off to the DECwindow 
Server? It would allow current UIS Development to operate 
transparently under X windows. 

Also, can you download an Image using UISSIMAGE to 4 plane 
GPX?. It seems to only load one bit plane. 

Keith Roberts 
ST Systems Corp 
109 Mass Ave 
Lexington, Ma 02173 
(617) 377-5959 


GRA-3 



Note 9.0 Flight simulator for VAXStations 

VAXFAM::DSTONE 

20 lines 1 l-DEC-1987 12:07 

This is the beginning of a campaign to get DEC to release 
Flight Simulator to the DECUS tapes. This is one of the best 
example programs that could be used to show non-computer 
oriented people what VAXstations can do. Besides that, it’s a 
great game to play. 

We should also get DEC to release the source code for all of the 
DEMO’s as well as the executables. I understand whv DEC 
doesn't want, to do this (after all, you may not want your 
company name on a product that is a midnite hack job, etc.) 


Electronic Publishing 


Henry Schneiker 

The current state of publishing falls into two broad categories. 
First are the traditional typesetters. They use photocomposition 
units that have been in use for the last 10 to 15 years. These 
machines can perform all the standard typesetting tasks used for 
layout of livers, brochures, periodicals and books. Typical 
typesetting involves creating parts of a page with the 
photocompostion system, printing them and then pasting the 
parts together by hand in order to create the final camera ready 
page. Typical costs run from $20 to $40 per page produced. 
One major problem with traditional typesetting is that, if a 
change is needed, the entire page, or publication, may have to 
be laved out again from scratch. 

The second broad category is electronic publishing. Electronic 
publishing is a recent phenomenon that uses a computer with 
special software programs to electronically create a full page (or 
several pages) on a computer screen. The software allows for 
electronic cut and paste, before the page is ever printed. Text 
can be inserted or deleted at will, and will "flow" back and 
forth along the layout automatically. Typical costs with 
electronic publishing methods run from $10 to $20 per page 
produced. This is a substantial decrease in cost over traditional 
typesetting for creating the same page. 

In addition, the computer can save the page for later use and 
can be easily revised if a mistake is encountered or if changes 
are desired. Typically, 10 pages can get minor revisions for the 
same price as creating the first original. This revision 
capability can reduce the final page cost by 50% to 70% for a 
single publication. 

The Macintosh computer has been credited with bringing 
"Desktop Publishing" to the mass market, which is simply 
electronic publishing with a small computer system. The 
Macintosh is used to lay out a page or full publication, and 
then the image of those pages are sent to a laser printer (Apple 
LaserWriter or other laser printers that use PostScript). What 
Apple really did was to make Desktop Publishing a common 
term and make cheap publishing a reality. There are many 
software packages on computers made by Apple, IBM. DEC, 
Prime, DG, CDC and others currently available for doing the 
same thing. 

The resulting output of the laser printers is very nice. They are 
a big leap from the older "dot matrix" printers, which has a 
resolution of about 75 dpi, used with most low end computer 
systems. Pages from these laser printers are suitable for office 
memos, correspondence and other standard uses where 
typewriter quality was once needed. The current technology in 
laser printers produces output with a resolution of 300 dpi by 
using almost the same technology used in the typical office 


However, I feel that the examples given in the actual code may 
be the best way of showing others how to do some of the nice 
things that the demos can do that a normal programmer can't 
figure out. 

Maybe we should all get together and send lots of postcards and 
phone calls to the DECUS graphics counterpart in DEC. 1 think 
it’s someone named Jim Flatten (sorry Jim; I couldn't resist). 
Actually, it would be a great program to have, and it really 
should be made public. 


photocopier. The average person does not notice the "jaggies" 
or roughness of the characters or other artwork at these 
resolutions unless they look closely. However, 300 dpi is not 
suitable for halftone picture production or other high quality end 
products. However, it is a good proofing device for both these 
areas. 

A new breed of laser printers are just emerging with a resolution 
of 600 dpi. These have been long in coming because of the 
problems with toner particle size. The visual quality is much 
higher then the current technology. Again, as with the 300 dpi 
models, these printers are not suitable for producing halftone 
pictures. 

Traditional typesetters have established 900 to 1000 dpi as the 
threshold of typeset quality. This is the minimum required to 
process text only. For producing halftone pictures, you need to 
be able to produce about 256 shades of gray for good quality 
work. When your printer talks about halftones, he makes use of 
a different measure, called lines. At the low end, 85 line 
halftone screens are the minimum quality used for newsprint 
applications. At the high end, halftone screens with over 150 
lines per inch are used. Most good typesetters use halftone 
screens in the 133 to 150 line per inch range. Printing 
technology is limited to reproducing halftones of about 250 lines 
per inch. About 1200 dpi is required to produce a halftone 
picture at 90 lines per inch. 

Laser typeset machines are capable of resolutions in the 2500 dpi 
range. This is equivalent to the quality used by publications 
such as National Geographies and Smithsonian. These high 
resolutions allow halftone screens of 150 lines per inch w'ith no 
perceptible change from one shade to the next. 

Once these high resolutions are available, it is possible to fully 
automate the page layout process so that no mechanical cut and 
paste is necessary. These printers print on photographic roll 
film, not with toner. The current genre of software is capable of 
making full use of this technology. A benefit of this technology 
is that a publication can be produced electronically and sent by 
phone or other electronic means to a distant site for final, 
faithful, reproduction and distribution. In fact, it is possible for 
the high resolution laser printers to print directly on offset plate 
material, eliminating the last intermediate step between editor 
and pressman. 

In 1984, Adobe Systems introduce a new printer language called 
PostScript. PostScript is a page description language that allows 
characters in any font describable, line art and halftones, to be 
combined on the same page in any way. Apple's LaserWriter 
was the first printer to make use of this language. Since then, 
PostScript has been accepted as the industry de facto standard, 
for low resolution printers all the way up to the high end printers 
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such as Linotron 300, even by the likes of IBM, DEC, HP and 
Xerox, not to mention most of the major laser printer 
manufacturers. Many of the page generation software packages 
today generates PostScript, and PostScript printers cover the 
whole range from inexpensive laser printers to the high 
resolution laser printers. PostScript files may be generated on 
one system and printed on another without any loss of quality. 
This is a first for the computer industry. 

Photocopying smears the 300 dpi jaggies produced by laser 
printers. As it turns out, second generation photocopies of the 
original laser printer output yield the best results from a high 
quality photocopier. This method of reproduction is tine for 
small quantities of fliers, business memos and the like. 

However, offset printing, with its much higher resolution, 
preserves the jaggies and the final printed page reveals the true 
source of the original. Offset printing is desirable whenever 
large (over 200) quantities are required or when more 
professional looking output is desired. 

The paper used also has an effect on the final quality. Rough 
papers tend to smear the edges of lines and characters. Glossy 
papers show everything, including defects and jaggies, in great 
detail. 

In addition to service centers, many busineses, authors and 
individuals have similar systems. Many need typeset quality, 
but there is nowhere to get it. There are over 400 packages on 
the market that generate PostScript output including TEX, 
Scribe, PageMaker and Interleaf, which are some of the main 
products used for the production of books, magazines and 
newsletters. 


Typesetters are estimating about 20% to 30% of their business 
has already been lost to electronic publishing. They are, 
themselves, looking at electronic publishing as a way to lower 
their cost and capture new business. 

The Linotron 300 has a rated resolution of 2540 dpi. It can 
print on standard rolls of RC photographic paper, transparency 
film and offset plate material. The latter can be taken straight to 
an offset press, mounted and run for 25,000 copies. 

The Linotron can produce output at about 3 inches per minute. 
With 12" wide rolls, that's about 3.5 minutes per page of text. 
Graphics and font changes proceed slower while lower resolutions 
proceed faster. A realistic average is about 4 minutes per page 
at full resolution or 15 pages per hour at 2540 dpi. About 80% 
of all typesetting involves text without graphics or pictures. A 
resolution of 1270 is adequate for text and allows a much faster 
production rate. The Linotron 300 can operate at 2540, 1270 
and 635 dpi. 

The Linotron comes with PostScript. This is the only high 
quality (over 600 dpi) PostScript printer on the market. The 
Linotron comes with a hard disk that can hold the available fonts 
and is also used for font caching. This allows most PostScript 
print jobs to be run without any intervention for font changing 
by an operator. 

The printer rolls exposed film onto a take up reel. From here, 
the take-up reel is placed in a developing machine for automatic 
developing and drying. The operator then takes the completed 
job(s) from the output tray, cuts the pages and packages them for 
delivery to the customer. 


GAPSIG Symposium Tape 


Mike McPherson, GAPSIG Librarian 

It is time tor the Spring Symposium. That means that it’s 
about time for another Symposium tape. The Symposium tapes 
are a great way to share software that you have written with 
others around the world who have similar interests and needs. 
Anything is fair game, including subroutines and libraries, 
complete programs, graphic images and databases, and write¬ 
ups on technical or other topics. 

As usual, there are two ways to submit to the Graphics tape: at 
Symposium or by mail. If you plan to attend the Spring 
Symposium in Cincinnati, bring your tape to the Symposium 
and drop it at the Library booth in the Exhibit Hall. It will be 
copied and returned to you. 


1 can accept any of the currently supported media and formats, 
but I would prefer 9-track, 1600bpi, VMS Backup format if 
possible. If you can’t attend the Symposium at Cincinnati, you 
can still submit. Just fill out the Tape Copy submission form at 
the back of the Cincinnati Preliminary Program and send it and 
your submission to me: 

Mike McPherson 

A. H. Case Center for CAEM 

Michigan State University 

236 Engineering 

East Lansing, MI 48824. 

If you have any questions, give me a call. My phone number is 
517-353-9769. 
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FROM THE EDITOR — Carmen D. Wiseman 


DEADLINE FOR THE NEXT ISSUE: MAY 23, 1988 

Time for another symposium! You may have noticed that there was 
no Cincinnati "roadmap" article in the last issue. Well, there 
won't be one in this issue, either; the usual list of sessions 
has had to give way to all the excellent technical contributions 
we've received over the past few months. 

Are articles like symposium roadmaps valuable to you, or 
would you rather see more technical articles in HARD NEWS? If 
the former, tell me or someone else in HMS leadership; if the 
latter, keep sending along terrific material such as the articles 
by Dennis Sullivan and Scott Taylor in this issue. I don't 
manufacture these newsletters out of spit and chewing gum, you 
know—a strong and appropriately "byte-headed" HMS newsletter 
depends on you and your contributions . 

Speaking of manufacturing newsletters, this will probably be 
my last HARD NEWS. Unfortunately, the person I drafted as my 
replacement has other commitments that prevent him from taking on 
the editorship, so we're sending out a call for volunteers for 
the position of HMS newsletter editor. Interested parties should 
get in touch with HMS SIG chair Bill Walker at the symposium, or 
contact him at the address on the facing page. 

We're also sending out a call for HMS session chairs at the 
Cincinnati symposium. There's a nonstop stream of sessions, and 
we need volunteers to spell symposium coordinator Mike Allen, who 
often ends up chairing many more sesions than any human being 
should. So, if you're planning to attend HMS sessions anyway, 
why not help out the HMS SIG by being a session chair? For 
details, contact Mike Allen at (415) 422-8326 or via DCS. 

cdw 
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SUBMITTING ARTICLES TO HARD NEWS 


The purpose of HARD NEWS, the HMS SIG newsletter, is to serve as 
a forum to share information related to DEC hardware with the 
members of the SIG. As such, the existence of the newsletter is 
entirely dependent on your contributions. If you have a hardware 
hints-and-kinks item, a better or safer way to do something, 
product news, a tutorial article of general interest, etc., we 
would like to publish it in the newsletter. We hope that HARD 
NEWS will be published at least six times a year. 

You can submit material to the editor, Carmen Wiseman, or to 
the HMS SIG chair, Bill Walker. We can accept submissions in a 
wide variety of formats: 

o Items can be sent to the editor on VMS-format RX50s, TK50 
cartridges, or IBM PC-format 5 1/4" floppies. The SIG chair 
prefers RT-11 floppies but can handle any reasonable media. 

o Hard copy, like cash, is always acceptable. Camera-ready 

copy will save us a lot of typing, but we don't insist on it. 
You can also use the Hardware Submission Form in the 
"Questionnaires" section of the combined SIGs Newsletters. 

o Those of you with access to DCS can send things to WALKER or 
WISEMAN. DCS is usually checked on a daily basis. 

o You can reach the SIG chair on CompuServe as 

"Bill Walker 71066,24" or via EasyLink mailbox 62752448 or 
MCI Mail account 333-1675. You can reach the editor via 
EasyLink mailbox 62960090 (be sure to say "TO: Carmen 
Wiseman" somewhere in the body of the message). 

If you have anything to submit, send itllf it is a mess, but we 
can read it, we will get it into the newsletter somehow. 

Finally, if you have any questions about submitting material, 
call one of us. The telephone numbers are listed below. 

Contributions can be sent to: 

William K. Walker Carmen D. Wiseman 

Monsanto Research Corp. OR Digital Review 

P.O. Box 32 A-152 == Prudential Tower, Suite 1390 

Miamisburg, OH 45342 800 Boylston Street 

(513) 865-3557 (work) Boston, MA 02199 N 

( 513 ) 426-7094/0344 (home) ( 617 ) 375-4361 (9 a . m.-1 J>. m . E&T) 
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FCO/ECO CORNER 


FPJll-AA Compatibility with the KDJll-AB Option 

OPTION: KDJll-AB 
MODULE: M8192-YB 

To support the use of the FPJll-AA floating-point accelerator on 
your KDJll-AB CPU board, you should ensure that the following FCO 
revisions have been made: 


A : Module part revision 
stamp? on side 2 of 
module. 

(i. e. B2 , Cl ) 


B : Module datecode stamp; 
on side 2 of module. 

( 504 , 625 ) 

C : Location of the etch 

revision and part number, 
(side 2) 

Cl : 50-15394-01 REV Cl 

Dl : 50-15394-01 REV Dl 

D : Location of 1,000 ohms 
resistor, soldered from 
pin 4 and 7 of IC, E31. 


This resistor is only 
used, if the etch rev¬ 
ision is "Cl", the colors 
are brown, black, red, 
and gold. 

R9 : Location of resistor 
R9. The value of R9 
changes depending on 
the etch revision of 
PC Board. 


** Cl : R9- 8,250 ohms 

(gray, red, green, 
brown,brown) 

RA : Location of a resistor of 680 Dl : R9- 1,000 ohms 

ohms for both etch, Cl and Dl. (brown, black, 

The colors are blue, gray,and brown. red, gold) 
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M8192 YB-YC Etch Cut 

(hole) SIDE 2 

X (solder side) 



1 - >5 

X : the etch cut location 
is in the second layer. 

, % ECO wires 

ETCH ' ' WIRE 

C1 X) Wire from E22 . 9 to E7 . 13 

2) Wire from E7 . 7 to E7 . 14 

3) Wire from £17 .9 to E5 .2 

4) Wire from E16 .13 to E13 . 41 

D1 U Wire from E22 . 9 to. E7 13 

2) Wire from E7 . 7 to E7 14 
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Bad Blocks on Winchesters 
with RQDX Controllers - Dennis Sullivan 


EDITOR'S NOTE 


This article comes to us from Dennis Sullian of 
Medisys in Phoenix, Arizona. Dennis comments 
that the information it contains is "an 
accumulation of bits and pieces I have picked up 
from reading and from talking to DEC engineers at 
DECUS symposia. I know of no other single place 
to read about and understand bad blocks on 
MicroPDP-11 systems. I felt compelled to write 
this article so that other people in my company 
besides myself could deal with the problem; now 
that I have written it, I would like to share it 
with other DEC users." 

Dennis adds that there may be other techniques 
for dealing with bad blocks and RQDX controllers: 
"Perhaps this article can serve as a catalyst to 
generate more discussion on the same topic. At 
the very least, someone out there must know how 
to use RSTS well enough to deal with this 
problem." 

We think this is what HARD NEWS is all about, and 
we thank Dennis Sullivan for contributing such a 
fine compendium of useful information. If you do 
have other techniques or comments, contact Dennis 
at (602) 993-4771 and/or send a submission to 
HARD NEWS (details elsewhere in this issue). 
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Bad Blocks 

on Winchesters with RQDX Controllers 


Introduction 

Winchester drives develop bad blocks. The RQDX family of 
controllers is designed to automatically map out these bad 
blocks in such a way as to cause as little trouble as 
possible to the user. Sometimes it causes a lot of trouble. 


How the Hardware Works 

The RQDX family of controllers all try to automatically map 
out bad blocks. Engineers continually make improvements, so 
the latest version of the RQDX3 controller does a better job 
than any of its predecessors. For the purposes of this 
write-up, the differences between these controllers is not 
important, only the basic design for bad block replacement. 

The winchester contains more blocks than are normally used. 
Spare blocks at the end of the disk are available to replace 
bad blocks. A bad block replacement table is maintained on 
the disk listing all of the bad blocks and their replacement 
blocks. Before reading or writing a block the controller 
always checks against this list. If the desired block is 
listed as bad, then the controller will automatically use its 
listed replacement block. The RQDX controller automatically 
uses and updates this table. 

Whenever the controller trys to read a block on the disk and 
experiences an error, it decides that a bad block is 
developing and the blocks should be replaced. A spare block 
is selected and the bad block replacement table is updated. 
The controller automatically trys several times to read the 
block that it had trouble with. Usually it gets a good read 
of the data and the user never knows anything happened. 

Sometimes the controller is unable to recover the data. It 
still maps out the bad block. It writes whatever data it 
could read into the replacement block. Because that data is 
no longer good, it marks that block as bad. Usually it will 
mark the block with a parity error. Sometimes it will mark 
it with a CRC error. Perhaps there are other ways to mark 
the data as bad. 

Regardless, if the replacement block is marked as having bad 
data, then this causes problems for the software. The 
software reports that it cannot read the block so the user 
assumes the block is bad. The truth is that the block is 
good, but the data is bad. This is a hard concept to 
understand, that on a Micro-11 the user never has to deal 
with bad blocks, only with bad data in the block. 
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Software Perspective 

System programmers have always been fighting with bad blocks. 
The operating systems have developed various schemes for 
handling bad blocks. RT-11 and RSX operating systems are 
discussed in more detail. The RT-11 and RSX operating system 
designers came up with different approaches for handling bad 
blocks. Now that the function is handled in the hardware, 
both of these two operating systems are faced with coping 
with the modern world. 


RT-11 Systems 

In RT-11, when a bad block is discovered on a RX01 or a RK05, 
the operator can avoid using that block by creating a file 
named .BAD in that location. The INITIALIZE command contains 
an option (/BADBLOCKS) which will automatically cover the bad 
spots with .BAD files. If a bad block develops in an 
existing file, then the user must find a good back-up copy of 
that file, and put it on a different part of the disk after 
first marking that block with a .BAD file. 

A new family of disk handlers came along with the RK06, RK07, 
RL01, and RL02 disk drives. The software handler for these 
drives maintains a bad block replacement table on the disks. 
The software handler automatically automatically reads and 
writes the replacement blocks. The software handler does not 
automatically replace the bad blocks though. The user must 
manually replace any bad blocks found, normally with the 
INITIALIZE/REPLACE command. If a bad block develops in an 
existing file, then the user must find a good back-up copy of 
that file and put it on the disk after replacing the bad 
block. 

Now that we have RQDX controllers, the rules have changed 
again. The hardware automatically handles the bad block 
replacement and mapping. The operator now needs to deal, not 
with bad blocks, but rather with bad data that most programs 
can't read because the programs are taught to give up if 
there is an error. If the problem is with an RX50 or RX33 
floppy, throw it away. If the problem is with an RD51, RD52, 
RD53, RD54, RD31, or RD32 then read on. 


Using RT-11 to Fix Bad Blocks on Winchesters with RQDX 
controllers. 

The block is fixed by writing to it. Either the same file or 
another file must be written to that location. After fixing 


it, use the DIR/BAD command to verify that the block has been 
written into. 

First, identify the block with bad data as well as the file 
containing the bad block. Use the DIR/BAD/FILES command. 

If the bad block is not in a file, then copy a file to that 
location. If necessary, just keep copying files until you 
have written over that block. When you copy a file RT-11 
will use the first space big enough to accomodate the file. 
Use the DIR/FULL/BLOCKS command to identify just what blocks 
need to be filled up before the bad block is written. 

If the file is easily replaced from a back-up set, then by 
all means do that. COPY/PRE the file to the disk, or reload 
the entire back-up. 

If there is no back-up, and the file must be saved, then 
someone has to be able to identify what should be in that 
block. Once it is identified, recover the rest of the file 
by deleting the file and creating two files, one in the 
portion before the bad block and the other in the portion 
after the bad block. Use the CREATE/START:n/ALLOCATE:m 
command to position these new files. Now the bad block is 
unused, so copy a file over it as described above. Once you 
have done this, you can delete the one block file, and the 
file covering the second portion. Use the CREATE/EXTENSION:n 
command to extend the first file to the proper size. Finally 
use SIPP to patch in the data you really want. 


RSX Systems 

The FILES-11 filing system used by RSX (also known as ODS-1) 
has the built in capability to take care of bad blocks. This 

is the way it has always been. RSX maintains a list of all 

of the bad blocks on the disk and avoids using those blocks. 
Before a disk is used by RSX, it must be initialized with the 
ANALYZE/MEDIA command which puts the FILES-11 structure, 
including the bad block list file, on the disk. When a bad 
block develops on the disk, it is not necessary to re-initia- 
lize the disk. With the oldest disk drives, (RK05s etc.) a 
new bad block is added to the list with the VFY utility. 

When the RK06, RK07, RL01, and RL02 disk drives came along, 
they fit in fine because the operating system software was 
still in charge of mapping out the bad blocks. The only 
difference is that the list of bad blocks is in a different 

place and the original list will normally never contain any 

bad blocks. When a bad block develops on the disk, it is 
still not necessary to re-initialize the disk. With these 
disk drives, a new bad block is added to the list with that 
same VFY utility. 
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Now that DEC has developed MSCP (Mass Storage Communication 
Protocol) devices (this includes the RQDX controllers with RD 
disks) the water is muddier. The list of bad blocks is now 
maintained by the hardware. The software still maintains its 
own list, but this list should never be used. When a bad 
block develops on the disk, it is not necessary to 
re-initialize the disk. It does no good to add the bad block 
to the bad block list. The VFY utility is handy to identify 
the bad block, but cannot be used to make the block readable 
again. 


Using RSX to Fix Bad Blocks on Winchesters with RQDX 
controllers. 

Remember that the hardware reports the blocks as bad because 
they contain bad data. The blocks are actually good because 
the hardware automatically mapped them out. The only way to 
fix that block is by writing into it. However, the block 
does not have to be fixed. The problem is that the block 
cannot be read. This means that the file cannot be backed 
up. Since RSX backs up only the existing files (ignoring the 
unused portions of the disk), deleting the file with the bad 
block is all that is required. The next time that block is 
used, it will be written into and it will no longer contain 
bad data. 

The problem is to identify the file with the bad block of 
data. Once the file is identified, it must be deleted and, 
if it is a required file, a good copy of the file must be put 
on the disk. 

If you are getting read errors on a data file, you already 
know which file has the bad block. If you are getting an 
error reported while making a back-up copy of the disk, then 
all you know is the file I.D. The trick is to translate that 
file I.D. into a file name. If BRU reports the file ID as 
000236000145 read that as file I.D. (236,145,?) where the ? 
is probably a 0. Only the first two numbers are required to 
uniquely identify a file and BRU reports them as two 
six-digit numbers run together. To find out the file name, 
use the 

DIR/OUT:CAT.DIR/ATT [*]*.*;* 

command to create a file CAT.DIR containing the file I.D. for 
all of the files on the disk. Use the editor to search this 
file to identify the file name for the known file I.D. 

An easier way to translate the file I.D. number to the file 
name is to use the VFY option /LI. However, most MicroRSX 
systems do not have the VFY utility program on them. 


Once you know the file name, delete it. If the file is 
necessary, then get a good copy of the file from a back-up 
set. If the file is part of a data set, then replace the 
entire data set to maintain a consistant set of data. 

If there is no back-up, and the file must be saved, then 
someone has to be able to identify what should be in that 
block. Worse yet, someone needs to be able to identify what 
should be in the whole rest of the file. The original file 
can be shortened with a 

SET FILE/END:(BLOCK:n,BYTE:0) fname 

command. The file can be re-extended by concatinating files 
with the COPY command. 

COPY BOOKS.GJC,ZERO.10 BOOKS.GJC 

is a command that makes a new copy of BOOKS.GJC with the file 
ZERO.10 appended to it. On my system, ZERO.10 is a ten block 
file full of null words. Be sure to 

PURGE BOOKS.GJC 

to remove the copy with the bad block of data. Finally, use 
ZAP to patch the file with the data that should be there. 
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Disk Benchmarking Tutorial - Scott Taylor 


EDITOR'S NOTE 


With this article, we continue Scott Taylor's 
series on disk benchmarking, which commenced in 
the last issue of HARD NEWS, with a tutorial on 
benchmarking methodology and DMA. Next time, 
we'll finish up with the specific results of 
Scott's benchmark tests of controllers from Aviv, 
Sigma, Webster, Micro Technology Inc. (MTI), 
Dilog, and Emulex. Stay tuned! 


TEST METHODOLOGY 

The first hurdle encountered when testing disk controllers is 
separating the disk controller overhead from the operating system 
overhead. I tried several different programming methods that 
reportly "eliminate" operating system overhead, but none worked 
reliably or repeatably. That's why I opted for a "hardware" 
approach which, combined with RT-11 V5.2, offers simple, 
repeatable control over disk controllers (or any I/O page 
device ) . 

By adding a Q-Bus signal decoding interface to the timer 
used for the memory response timing (see Hardcopy , January 1987, 
"Q-Bus Memory Access Times are the Result of Several Factors," 
and the HMS newsletter in DECUS SIGs Newsletters, March 1987), I 
was able to measure disk controller performance directly. Using 
only MSCP protocol information, no device-specific technical 
information was required for the controllers. 

MSCP and RT-11 

The RT-11 V5.2 manual set gave a brief (not nearly detailed 
enough) explanation regarding setting up.a DU driver using the 
SET commands. RT-11 requires a disk larger than 33MB to be 
partitioned (divided up), with a maximum of 33MB in up to eight 
partitions (268MB maximum per drive). Some disk controllers also 
give you the ability to partition a disk "in hardware," but this 
may further confuse the issue for a user new to MSCP. 

If you want help in using the standard DU drives, contact 
Omnex Inc. in Mountain View, California, (415) 966-8400. The 
company offers a "giga-handler" DU driver that enables using 
disks larger than 268MB. 

Disk Controller Benchmark 
Definitions and Descriptions 


Under MSCP, the sequence of events for a controller benchmark is 
always the same, regardless, of CPU or operating system 
(including MicroVMS): 

1. The CPU polls the controller (says "hey, you!") by reading the 
IP (initialization and polling) register. 

2. The controller reads command information from the DU driver 
using direct memory access (DMA). 

3. The controller transfers data to or from disk to memory. 

4. The controller writes command completion information back to 
the driver using DMA. 

5. The controller interrupts the CPU to indicate command 
completion. 

The controller poll can be detected by decoding the controller 
address (172150 in this case) off the Q-Bus. 

You can separate the command and data DMA transfers by 
watching the Q-Bus address used for the transfer. If the 
transfer is in the program space, it is data; if not, it is 
command DMA. I determined program bounds from the .SAV image 
link map. 

An interrupt on the Q-Bus always includes asserting BIRQ4L 
(interrupt request level 4) independent of interrupt priority. 

If you watch BIRQ4L and remove or don't use any other 
interrupting device during tests (in particular, avoid console 
terminal output), all interrupts will be from the disk 
controller. 

You can measure the total transfer time by having the poll 
start a timer and letting the interrupt {BIRQ4L) stop it. You 
can then divide the number of bytes transferred by the total 
transfer time to determine overall bytes per second (overall 
transfer rate) . 

CONTROLLER OVERHEAD 

Front and Back End 

The front end is the interval between the time when the 
controller is polled until the time when the first data transfer 
occurs, not including head seek time or rotational latency. This 
time is controller dependent. 

The back end is the interval between the last data transfer 
and the time when the controller generates an interrupt. This 
time is also controller dependent. 

In my tests, read results for front- and back-end controller 
overhead were generally in the range expected. Write results may 
look a little unusual: The time between the last [DMA] data 
transfer and BIRQ4L can include some disk rotational latency, 
which is not a delay caused by the controller. 
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Seek, Latency and Other Variables 

Head seek and rotational latency are the unknowns; they are 
dependent on the head position resulting from the previous 
request and the rotational position due to time. The method I 
used to "eliminate" both of these factors was to perform each 
operation 300 times, staggering the start time a little for each 
operation. (Delay = delay + ~3.0E-03 seconds; when delay was 
greater than 16.E-03, or about one revolution of the disk, 

16.E-03 was subtracted.) Differences between maximum and minimum 
times approached 16.67 milliseconds (one revolution of rotational 
latency) for repetitions above 100 tries, indicating the 
technique was valid. 

Here are explanations of some of the important (and 
sometimes confusing) variables relating to seek and latency: 

Head seek time: The time taken for the disk drive to move the 
head from the track it is currently on to the desired track. 

These times are commonly called "seek times" and may be given as 
average, track-to-track or maximum. This time is disk drive 
dependent. 

Rotational latency: The time taken for the disk to spin from its 
current position to a position where the desired data is under 
the head. This time will be between 0 and 16.67 msec (3600 rpm = 
60 rev/sec = 16.67 msec/rev) for most newer drives. The disk 
drive specs usually give 8.3 msec (one-half revolution) as 
average rotational latency. This time is also disk drive 
dependent. 

Disk transfer rate: The rate at which the disk passes data to 
the controller. This rate is determined by the disk clock rate, 
10 and 15 MHz respectively for the CDC and Maxtor drives I used 
in my tests. The actual data rate will be 16.67 msec divided by 
the number of sectors per track times 512 (512 bytes per sector; 
sectors = blocks). 

The transfer rate for the CDC drive is 1.044 to 1.105 MB/sec 
(34 to 36 sectors per track, depending on the controller used) 
and 1.566 MB/sec for the Maxtor drive (51 sectors/track for each 
of the controllers tested). This figure doesn't include spare 
sectors, as they don't actually contain data—or rather, the 
sector they replaced doesn't. 

DMA data transfer rate: The rate that the controller passes data 
to the memory [over the Q-Bus]. First, the number of words read 
or written are counted while the time that the controller has DMA 
privileges is measured (BSack is asserted). Then the number of 
words transfered times two (2 bytes per word) is divided by the 
"BSack" time. This yields the DMA transfer rate, which is both 
controller and memory dependent. I performed my tests using a 
Clearpoint memory in block mode and an Andromeda memory in both 
block mode and non-block mode (BREF response disabled). 


Important: I used the Andromeda memory in non-block mode to 

simulate the effect of using a high-performance controller with 
non-block mode memory. I do not recommended disabling block mode 
on any device without knowing what you are doing! 

Dwell time: The time between when a controller gives up the bus 
and asks for it again. For testing, I used BSack negated to 
BSack reasserted. Sometimes BSack negated to BDMR (DMA request) 
is used; DMA protocal specs are unclear as to which is correct. 

The difference between the two is CPU dependent and was constant 
for all controllers tested. Dwell time is controller dependent 
(a small minimum is caused by the CPU DMA grant latency and grant 
handshaking). Depending on the machine, the CPU itself may 
execute a single bus cycle (memory fetch or store) between the 
negation of BSack and assertion of BDMR by the controller even if 
BSack and BDMR occur simultaneously. 

DMA, BLOCK-MODE AND OTHERWISE—WHAT IS IT? 

All forms of DMA have one thing in common: in each case the disk 
controller, the device wishing to become bus master, must ask the 
CPU, the bus arbitrator, for permission to use the bus—in other 
words, to become the bus master—before beginning a transfer. 

The CPU will always grant the request, usually when the current 
bus cycle is complete. When the DMA transfer is complete, the 
disk controller releases control of the bus. 

Since the CPU cannot service any other requests or respond 
to another device on the bus, certain limits have been set to 
prevent any device from "hogging" the bus: 

1. A bus master must wait a minimum of 4 sec (dwell time) after 
completing one transfer before beginning another in all DMA 
modes. BSack negated to BDMR asserted (or BSack reasserted, 
depending on interpretation). 

2. A maximum of 16 words (8 if another device wants the bus) in 
block mode and 4 words in burst mode may be transferred per DMA 
request. 

The first limit is an attempt to give other devices a chance to 
have their DMA requests granted and to allow the CPU enough time 
to service interrupts. If an interrupt from a serial port is not 
serviced before the next character arrives, the data [in the 
serial port UART] gets written over or lost. One indication of 
this is when input from a keyboard is ignored during a disk 
transfer. (Note: "Ignored" means never acted on, "delayed" 
means not fast enough to suit the operator.) Data-late errors can 
indicate that other DMA devices (especially tape controllers) are 
not getting fast enough access to the bus. 

The second limit is an extension of the first. If two 
devices want the bus, both must settle for less time more often. 
This helps to avoid the problem of data-late errors. 
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In block-mode DMA / the disk controller gives the memory one 
address and then transfers up to 16 words (maximum) of data—8 
words maximum if a DMA request is outstanding from another 
device. When the transfer is done, the controller releases the 
bus until ready to begin the next transfer. 

In single-word DMA , the disk controller gives the memory one 
address and one word of data. The controller then gives back the 
bus and asks again when it is ready for the next transfer. 

In burst-mode DMA , the disk controller gives the memory one 
address and one word of data. This can be repeated for a total 
of 4 words. The controller must then give back the bus and ask 
again when it is ready for the next transfer. 

Actually, the phrase that needs to be added to each of these 
explanations to make the rules clearer is "until it is ready for 
the next transfer or 4 //sec, whichever is longer". 

Using block-mode DMA (at approximately 3MB/sec, a controller 
will require the bus for 10 /jsec. It must then stay off for 4 
//sec. If another device requests the bus, it can use that 4 //sec 
left by the first device plus 6 //sec more. This means that two 
devices can use up 100 percent of the bus time (until one is 
finished) without violating any spec limits. 

Sixteen words take 8 //sec (or longer) to transfer, plus 
address cycle time. Add to that time 1 or 2 //sec of CPU DMA 
grant latency. The result is about 10 //sec for 16 words (32 
bytes). In the case of the a single transfer, the total time 
would be 5 msec. For double-buffered I/O using two 16,384-byte 
buffers, the bus could be tied up for at least 10 msec, best 
case! Granted, this situation is rare and requires very fast 
disk drives, cacheing controllers or RAM disks, but it does occur 
and is not easy to diagnose. 

When two controllers want the bus, each will use it for 6 
//sec—long enough to transfer 8 words at 3MB/sec plus DMA grant 
time. Since the second controller will use the bus for 6 //sec, 
the first controller can request the bus before the second 
controller completes its transfer. As DMA requests take priority 
over CPU operations—including interrupt servicing—the CPU will 
grant the requests immediately and the controllers will use 100 
percent of the bus time. 

Strangely, the DMA specs limit the number of words 
transferred, not the amount of time taken to do it. Bus timeout 
specs do limit any single transfer (at least the DIN to REPLY 
portion of it) to a maximum of 10 //sec. This means that a 
controller could take 160 //sec or longer to transfer 16 words and 
still within remain in bus spec. 

A better approach would have been to set a maximum limit on 
the time used during a transfer rather than a limit on the number 
of words—for example, 20 //sec maximum per DMA transfer and a 


minimum of 6 //sec "dwell" between transfers. (In this case, 
"dwell" means that no DMA device can request the bus.) 


The device just completing a transfer must wait an 
additional 2 //sec to allow lower-priority devices time to make a 
DMA request. This would let most devices keep up with their disk 
or tape without blocking the CPU from servicing interrupts. 

Faster controllers would be able to transfer more than 16 words 
per DMA arbitration, providing an extra incentive to make better 
use of DMA time. Note: The MicroPDP-11/73 and 11/83 cache 
invalidation counters require an address cycle, not DMA 
rearbitration, whenever a 16-word boundary is crossed. 

Some manufacturers include the word "adaptive" along with 
block-mode DMA. This usually means that the controller transfers 
up to 16 words while watching to see if another device wants the 
bus, implying that "nonadaptive" devices either do not transfer 
16 words or do not watch to see if other devices want the bus. 

As far as I could tell, this term didn't originate in any DEC 
literature. block-mode DMA specs require devices to give up the 
bus after 8 words if another device wants the bus, period. 

Devices that do not monitor for other devices must stop at 8. 
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FROM THE 

EDITOR'S KEYBOARD 


Your editor must admit to a 
crushing blow. He has been scooped by 
a rival editor, Bruce Mitchell of the 
Multitasker. Bruce was first to the 
presses with earth-shaking news 
concerning a joint development 
project between Alan Frisbie, 
fearless leader of the intrepid IAS 
forces and Sharon Johnson of the VMS 
SIG, (nee RSX.) When I read a preview 
of his article for the April M/T, I 
immediately realized that I had been 
beaten to the keyboard. Please check 
the Multi-Tasker for full details on 
this important project. (Now I 
understand his DCS mail remark about 
the phone not ringing in his 
bedroom.) 

This issue contains an article by 
Steve LeFevre on running IAS on 
11/84's to take advantage of all 
available memory. Had hardware and 
software deadlines not intervened, it 
would have been in last month's 
issue. Thanks Steve. 

Remember the problems we had with 
the LN03 overheating last month? 
Turns out we had a problem with a bad 
ozone filter blocking the exhaust 
fan. Soon as Danny removed the 
filter, the LN03 went back to normal. 
Since it makes little sense to filter 
out ozone there and then generate it 


with an anti-static device on the 
line printer right next to the LN03, 
we are running with the filter 
temporarily out. 

And finally, our program of the 
month department, Peter Desselt of 
AECL Medical and Hans Goebel of 
Michael Reese Medical Center have 
pooled their efforts to provide a 
"Universal Debugging Flowchart" we 
hope it meets with your approval. 


CONTRIBUTION 

GUIDLINES 


Contributions of articles, SPR's, 
letters, etc. will be accepted in any 
form, (including notes jotted on 
stained tablecloths.) They will be 
more graciously accepted in one of 
the following formats: 

Paper submissions will always be 
accepted. Their publishing may be 
delayed until the editor gets some 
time at the keyboard to convert them 
to our current format. We can accept 
paper submissions by FAX. 

Contributions may be submitted on 
9-track Mag-tape, (800,1600, 3200 or 
6250 BPI,) DEC-tape II, and DecMate 
or RT11 floppies. We're not fussy, 
we'll even accept paper tape or 
cards. We can read any IAS/RSX, 
RT11, VMS fromat. 
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We have 2400/1200 baud modems on 
our IAS system and our VAX, with 
KERMIT for electronic submission. 
Give the editor a call @ (312)- 791- 
8075 (preferably later in the day,) 
to obtain access information, etc. 
Any media sent to us will be promptly 
returned. 

If you have a problem you would 
like to submit to the Devias wizzard, 
send it to the Editor at the 
following address. Answers to 
problems from members (or anyone) 
should also be sent to the Editor. 

Frank R. Borger 
Michael Reese Medical Center 
Department of Radiation Therapy 
Lake Shore Drive at 31st St 
Chicago, IL 60616 


TEN YEARS 
AGO THIS MONTH 


A letter to the Editor requested 
help in booting an 11/40 from RK06 
drives. The user could boot their 
RK05 drives, but their BM873-YA 
bootstrap would not boot their newer 
RK06 drives. That user didn't know 
beans about their hardware. The 
M873-XX series was a very early diode 
rom bootstrap, containing a massive 
128 words per quad card, and it never 
was upgraded to boot the RK06/RK07 
drives. That user must have gone on 
to bigger and better things with the 
Shuttle software, since they worked 
for NASA at the Kennedy Space Center. 

A report on a working group 
session on SPR problems at the Fall 
DECUS mentioned concerns with SPR 
reporting that seem to be with us 
even today. Some of the items 
mentioned were (1) A machine readable 
SPR form, (2) Publish all Patches, 
(3) How do I get SPR forms when I run 
out?, and (4) I'm not getting my copy 
of the Software Dispatch. 


And finally, one rather naive SPR 
complained that macro listings went 
to LP0: rather than CL: as the user 
expected. (Evidently the user never 
understood the effect of redirecting 
luns of programs like MACRO.) 


4 MBYTE MEMORY 
ON PDP-11/84'S 


Steve LeFevre 
Eaton Corporation 

Information Management Systems Div. 

31717 La Tienda Drive Box 5009 
Westlake Village, CA 91359 M/S 228 
s f1@ETN-WLV.EATON.COM 

PDP-11/84, 11/70 and 11/44 can 

support 4 Mbytes of memory with 
certain restrictions. This article 
will outline the restrictions on 
11/84 and 11/70 computers. Details of 
PDP-11/44 memory management will not 
be covered. The Oct. 1987 Multi- 
Tasker (contained in the Dec. 1987 
SIGs newsletters) contains a very 
good article on 11/34 and 11/44 
memory by Barry Essig and Michael M. 
Tsuji of Grumman. 

The PDP-11/84 and 11/70 processors 
both use twenty-two address lines to 
access memory. Twenty-two address 
lines provide an address space of 4 
Mbytes. While 4 Mbytes can be 
addressed, not all of the address 
space can be used for memory. Some of 
the address space is reserved for 1/0 
devices and the UNIBUS. 

The highest order 8 Kbytes of the 
address space is reserved for the 
UNIBUS 1/0 page. The 1/0 page is 
reserved for CPU and 1/0 registers. 
The 1/0 page is where the Command and 
Status registers (CSR) of peripheral 
device controllers are located in the 
memory space. References to 

addresses 17760000 to 17777777 will 
access the 1/0 page. 
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PDP-ll/70s have a further 
restriction on the amount of memory 
usable. The hardware memory 
management of PDP-11/70 limits main 
memory to 3840 Kbytes (1920 Kwords.) 
The additional 248 Kbytes are 
reserved for the UNIBUS map for DMA 
transfers beween main memory and 
UNIBUS devices. Memory could be 
placed in the UNIBUS map address 
space, but at the cost of losing the 
use of UMR registers in the UNIBUS 
map which are used for DMA mapping 
between UNIBUS devices and memory. 

PDP-11/84 memory does not have the 
restriction on the use of the 248 
Kbytes UNIBUS Map space that the PDP- 
11/70 memory has. Only the 8 Kbytes 
I/O page address space is restricted 
from use by memory on the 11/84. 

The PDP-11/84 can still use the 
UNIBUS map to perform DMA, but it 
does so without giving up main memory 
address space. The PDP-11/84 then can 
use slightly more memory than a PDP- 
11/70. Figure 1 on the last page 
compares the address space of the 
PDP-11/70 and the 11/84. 

NOTE: The "PDP-11 UNIBUS Processor 
Handbook" incorrectly specifies the 
maximum physical memory of the PDP- 
11/84 as being 3840 Kbytes (Appendix 
A.) The "PDP-11/84 Technical manual" 
and the "KDJ11-B CPU Module User's 
Guide" give the correct information 
on addressability of PMI memory. 

A source of confusion about the 
amount of memory available for a PDP- 
11/84 running IAS is due to the 
different methods used by IAS and the 
PDP-11/84 hardware to display the 
amount of available memory. A PDP- 
11/84 with a full 4.0 Mbytes will 
display the message. 

Memory Size is 4088 K bytes. 

After a reset or on power up. Notice 
that the PDP-11/84 has already 


subtracted the 8 kbyte I/O page 
from the 4.0 Mbytes, (4 mbytes = 4096 
Kbytes,) of installed memory. When 
IAS is booted on the PDP-11/84 with 
4.0 Mbytes of memory, the following 
message is displayed. 

2043K (word) IAS version 3.2B 

The IAS boot message uses word size 
measurements, while the PDP-11/84 
hardware uses byte size measurements. 
Notice also that IAS has also 
subtracted the 8 Kbyte I/o Page. 
Additionally IAS has rounded down the 
memory size to the nearest Kbyte. The 
display message only shows to the 
Kbyte, not to the exact byte count. 
Since IAS begins its count at 0 
rather than 1, the memory size is 
rounded down by 1024-1. The memory is 
this last unreported Kbyte is still 
accessible by the IAS software. 

Why put a full 4 Mbytes of memory 
in a system if it is not all usable? 
Because memory comes only in 1 Mbyte 
increments for the 11/84. The loss of 
the user of 8 Kbytes on a PDP-11/84 
or even 256 kbytes on a PDP-11/70 is 
small compared to the total capacity 
of a 1 Mbyte or 2 Mbyte memory board. 

The only problem identified with a 
4.0 Mbyte PDP-11/84 is with the IAS 
[11,17JQASGN.CMD command file. This 
command file will abort at line 111 
or 126 when the question if memory 
size is asked. The maximum range 
specified is 1920K words but the 
default is set to the <MEMSIZ> of the 
indirect command file processor. The 
command file bombs with a BAD RANGE 
OR DEFAULT SPECIFICATION error. The 
simple fix is to edit 
[11,17[QASGN.CMD and change the max 
range to 2043 at lines 111 and 126. 

Nothing else needs to be done to 
configure a system with 4 Mbytes of 
memory. The hardware automatically 
disables memory in the unusable 
memory space and the IAS operating 
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system automatically sizes available 
memory each time it is booted. 


PDP-11/84 PDP-11/70 

Physical Address Space Physical Address Space 


4.0 Mbytes +-+ 

| I/O Page | 

I I 

j 8 Kbytes j 

+-+ 


| Available | 

3.75 Mbytes + Memory + 

i i 

/ / 

/ / 

i i 

j 4088 Kbytes j 

I I 

0.0 Mbytes +-+ 


17777777 +-+ 

| I/O Page | 

I I 

j 8 Kbytes j 

17760000 +-+ 

| UNIBUS Map | 
j Address spacej 

I I 

j 248 Kbytes j 
17000000 +-+ 

I I 

/ / 

/ Available / 
| Memory | 

I I 

j 3840 Kbytes j 
00000000 +-+ 


THE PROGRAM OF 
THE MONTH CLUB 

Peter Desselt 
Hans Goebel 

Often when trouble-shooting a 
recalcerant piece of code, even 
seasoned veterans will fail to find 
all the bugs, or take too much time 
to fix a problem, (at least that's 
what my boss says!) This is often due 
to not following a sound, logical 
trouble-shooting proceedure. 

The following flow chart, if used 
properly, will enable even rank 
beginners to completely debug 
fiendishly diabolical problems with 
speed and ease. It can be applied to 
all levels of code, from machine 
language up to n-th generation 
languages, with equal facility. 

Remember, the flow-chart must be 
followed rigorously, or its true 
advantage will not be felt. 
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EDITOR’S NOTES 


Things are definitely gearing up for the Spring Symposium. This issue of Leverage 
should reach you just prior to the symposium, and there are some items of 
interest for that symposium included. 

TABLE OF CONTENTS The continuing saga of the Fortran 8X standard continues. DEC’s responses to the 

standard are presented here by Joel Clinkenbeard and Denise Lagasse. I’m sure the 
issue of the Fortran standard will be discussed in Cincinatti. 
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41 
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The results of a survey taken at the fall symposium by CSSE are presented by 
Pamela Blotcky of Digital. Many surveys have been taken at the symposia, but 
this group consistantly feeds the results back to us. Thank you. 

Notes from the last L & T Woods meeting give you an idea of the functioning of 
the SIG, and the directions we are pursuing. If you are interested in contributing 
to the SIG, or have concerns regarding where we are going, this should give you a 
good idea of what we are about. 

Next is the ever popular Release Status information for the various VAX 
Languages and Tools. 

Finally, the wishlist questionnaire for the L & T SIG is included. We would like 
to make the wishlist procedure a major part of the functioning of the SIG, but it 
will work only if you contribute. Please fill in the questionnaire, and return it to 
the indicated address. 

On a final note, I’m still looking for submissions for forthcoming newsletters. If 
you would like to submit electronically, I can give instructions for logging into 
my system and using Kermit. If you submit hardcopy and go to all the trouble of 
formatting the material nicely, please, PLEASE make sure you print in a large 
(12pt or so) type. By the time the newsletter is reduced for printing, normal 10 
pt type is nearly unreadable. In any event, please consider submitting something , 
in whatever format. 

A1 Folsom 
Leverage Editor 
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1 Introduction 

During the week of 7-11 March, I attended the first-quarter meeting of the 
Joint Pascal Committee, which was held in Monterey, California. 

The Joint Pascal Committee, hereafter referred to as the JPC, is jointly 
sponsored by ANSI and the IEEE. JPC works closely w T ith its ISO coun¬ 
terpart, ISO/IEC JTC1/SC22/WG2. 

In October of 1986, JPC produced a draft for the new Extended Pascal 
standard. The draft contains some interesting extensions that would make 
standard Pascal a viable language. 

The comment period for the draft ended May 1st of 1987. At this 
meeting, JPC finished evaluating the over 700 distinct comments from 35 
different sources received during the public comment stage. 

2 Issues 

There w T ere not as many substantive issues discussed at this meeting com¬ 
pared to previous meetings, because most of the issues had been resolved 
except for details. Much of the meeting consisted of proofreading the new 
draft and reconciliation of all of the changes that have been made. 

I was somewhat thrilled that text I had personally written made it into 
the draft document itself. (Of course, it was only the foreword, which offi¬ 
cially isn’t part of the Standard, but hey, it’s the only place in the document 
where regular English appears anyway—the rest is in Standardese. 

Some of the proposals were rejected for the current draft, but w r ere 
passed on to the Extensions Task Group (ETG) for possible inclusion in a 
future version of an unnamed standard. 

Many of us were determined to finish up at this meeting to keep from 
delaying the standard any more than it has been delayed already, so I 
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voted against anything that couldn’t be implemented during the meeting, 
no matter how much I would have liked to have it. A standard that doesn t 
have everything that you would like is better than no standard at all, w r hich 
is the probable result if the process keeps dragging on. 

The following issues were discussed: 

2.1 Short Circuit Evaluation of Boolean Expressions 

The short-circuiting issue raised its head again, at least temporarily. This 
had finally been resolved at the December Miami meeting, with refinement 
at the WG2 meeting in February (short-circuiting was simplified by giving 
and-then and or_else the same precedence as the regular and and or), 
but one of the comments resurrected once again the idea of implementing 
short-circuiting by subverting the and and or operators. I was expecting 
another fierce battle and was ready to jump in with both feet, but the 
committee rejected the proposal immediately, not wanting to turn that 
rock over again. 

2.2 Spam, Spam, Spam 

Much time at the meeting w r as consumed with debate on the topic desig¬ 
nated (for reasons too complex to go into here, although Monty Python 
and Vikings were involved) as the “spam” issue. The heart of the problem 
was that the operation of the textual I/O procedures (read, readln , etc.) as 
specified in the draft w r as ambiguous under certain conditions, causing the 
possibility of different results from different implementations. After wran¬ 
gling with this offline several times during the week, the Spam Task Group 
finally hit upon the right wording to lock down the definition. 

A similar problem with the end-of-line processing was resolved. 

2.3 Comparison Data Type 

It was proposed that a new predefined type comparison be added to Ex¬ 
tended Pascal, defined as the enumerated type consisting of greater , equal, 
less , connected , unrelated , sub , and super , and that a new operator to com¬ 
pare two operands and return a result of type comparison should also be 


added. This value could then be used in a case statement. 

This proposal was far too complicated to be considered at this late date, 
but w r as passed to the ETG for future consideration. 

2.4 Storage Allocation Control 

A proposal for direct control of the storage allocation of variables w r as eval¬ 
uated. Many times a system programmer needs to access an object external 
to the Pascal run-time environment, such as an operating system data struc¬ 
ture. It would be convenient to access this object with regular Pascal record 
notation, but the physical layout of records is implementation-dependent 
and cannot necessarily be mapped to match the external object. A means 
for forcing size and alignment (bit, byte, word, etc.) of fields would solve 
this problem. 

The proposal was rejected for the current draft due to time constraints, 
but was passed to ETG for future consideration. 

2.5 Time Granularity 

There w T as a proposal that finer granularity be added to the time facilities 
of Extended Pascal, since the current version of the draft only goes dow r n to 
the second. While higher resolution is very desirable, it is very complicated 
to add this feature in a portable w r ay, given the wide range of hard-ware and 
clock resolutions. 

The proposal was rejected for the current, draft, but -was passed to ETG. 

2.6 Pointer Comparison 

The only comparisons -which can be performed on pointers are equality and 
inequality, since no other comparisons make sense with pointers. One of 
the proposals suggested ‘<’ and *>’ be allowed also. This would allow you 
to use 

(p < q) 

as a shorthand for 


(p = nil) and (q <> nil) 
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While this saves a few keystrokes, it is obscure to the point of incompre¬ 
hensibility. Furthermore, although this wasn’t brought up in the meeting, 
it assumes that the underlying value of nil is zero, or at least less than a 
valid pointer, w'hich is not a requirement of the standard. The value of nil 
can be any value the implementation wishes to use, as long as it can be 
differentiated from a valid pointer. The committee soundly rejected this 
concept. 

2.7 Record and Array Comparison 

There was a proposal to allow comparison of complete structures such as 
arrays and records. On the surface, this seems like a simple thing to do if all 
you are talking about is equal or not equal (other operations like less than 
or greater than are meaningless for records and arrays—one field in a record 
could be greater than its counterpart in the other record w T hile a different 
field could be less than its counterpart), but the compiler implementors 
present said that even equality is not as straightforward as it appears to 
be because of slop bits, variants in records (especially untagged variants), 
and other gotchas. The slop bits, w T hich are a result of alignment to byte 
and w r ord boundaries, are not really part of the record, but are physically 
present wdthin it. A block comparison of tw’o records (such as with the 
VAX cmpc3 instruction), w r ould compare the slop bits of the records as 
well, which are undefined and probably contain garbage. Initializing the 
slop bits could eliminate this problem, but not without cost. Static records 
could possibly be initialized at compile-time, although many (if not most) 
compilers don’t initialize static variables to zero or other known states like 
the VAX does. Heap and stack records can be initialized only w r ith run-time 
overhead. 

Since block compare appeared infeasible, the suggestion was made that 
the compiler generate inline code to compare the individual fields of the 
record separately. While a lot of code would have to be generated to do 
this, the user would have to generate an equivalent amount manually, and 
hopefully the compiler code would be more efficient. The variants are the 
problem here. Unless the compiler does full variant checking, there is no 
way for it to determine which fields are currently active and should be in¬ 
cluded in the comparison. With untagged variants, it is impossible, since 


knowledge of the active variant is present only in the mind of the program¬ 
mer. 

Even with all of this, I might have voted for record and array compari¬ 
son, possibly accepting the restriction that untagged variants could not be 
used, but it w’as too significant a change to be incorporated by the end of 
the meeting. 

2.8 Relvalue 

The relvalue procedure, which is used as a general type escape for ordinal 
types, was eliminated and w r as replaced wdth a tw’o-parameter generalization 
of the succ (successor) procedure. 

2.9 Bindability 

The bindability issue returned again. This time the debate centered on 
details about bindability, such as: if you have a bound record containing a 
field which is itself bound, and you unbind the record, w'hat is the state of 
the field? 

Some topics w r ere easy to resolve, such as 

• it is an error if the bind or unbind procedures are used on a variable 
that has not been designated as bindable 

• it is OK to unbind a variable that is not currently bound 

• it is not OK if an already-bound variable is bound a second time 
without first being unbound from the first thing. While the imple¬ 
mentation could do an automatic unbind, this is a hidden operation 
masking a probable error 

2.10 File Variables With Variants 

The ability to have file variables within the variant part of a record had 
been removed at a previous meeting. It was decided at this meeting that 
the capability must be restored, since it is currently permitted in “classic” 
(unextended) Pascal, and the committee is obligated to remain compatible 
whenever possible. 
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2.11 Rampant GOTO 

One of the more bizarre proposals received by the committee was to com¬ 
pletely relax any restrictions on goto targets—including jumping into the 
middle of loops and other blocks and I suppose into the middle of proce¬ 
dures. Apparently the idea was to allow a programmer to bypass all of 
Pascal’s control structures and do all branches manually with goto state¬ 
ments, making it possible to write BASIC “spaghetti code” in Pascal. 
Needless to say, this comment was vehemently rejected. 

3 Standards on Floppy Disk 

X3 has indicated that in the near future, standards documents may be 
available in machine readable form, such as floppy disk, as well as paper. 
This would make it much easier for manufacturers to incorporate parts of 
the standard into their manuals. Unless the disks are a lot cheaper than 
the printed documents (unlikely), it is unclear if there is any advantage 
in getting the standard on disk for someone who only wants to read the 
document. 

4 Next Meeting 

The next meeting of the Joint Pascal Committee will be held in Alexandria, 
Minnesota, June 13-17. 


when they become available. 

The draft will be available from Global Engineering, same as the FOR¬ 
TRAN 8X draft, for a similar price. I believe the document number will 
be ANSI/IEEE770X3.160-198X, although this should be verified before or¬ 
dering. 

While anyone who wishes to make a public comment on the draft may 
do so, serious comments are preferred since the committee is required to 
respond to every comment and the comments and responses are distributed 
worldwide. The comments can either be sent directly to the X3 Secretariat 
or to me to be forwarded to X3 with a cover letter. The comment period 
will probably be in the August-September timeframe, and will only be two 
months long this time. If you relay your comment through me, be sure to 
send it well before the close of the comment period. 

When a public comment is submitted, there are a few things the sub¬ 
mitter can do to make life easier for the committee. The printing should be 
as legible as possible, since the comment will be reproduced many, many 
times, often with reduction. The various issues should be cleanly separated 
with paragraphs, bullets, etc., because the committee evaluates them inde¬ 
pendently. Because w r e have to wade though a lot of text, headings and/or 
numbering would be very helpful, such as: 

1. Bindability. I feel that the concept of bindability is a load of ... 

2. Private Types. This is nice feature, but I would suggest ... 


5 New Draft 

Since technical changes have been made, a new draft will be published and 
the review cycle will begin again. Once the draft is available, I will make 
sure that an announcement is made in a DECUS publication so that people 
can get copies of it. The draft will be too big (100+ pages) to be printed by 
DECUS in its entirety, but possibly the foreword (including the immortal 
prose written by yours truly that was mentioned above) can be printed. 

I will be working with the committee member responsible for publicity 
and he will supply me with a machine-readable press release and foreword 
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To: ANSI X3 Secretariat 

From: Joel Clinkenbeard 
Denise Lagasse 

Digital Equipment Corporation 
110 Spitbrook Road 
Nashua, NH 03062 

Dept.: Technical Languages and Environments 
MS: ZKO2-3/N30 

Ext.: 603-881-2049 

Date: 22 February 1988 

Subject: Digital Equipment Corporation comments on X3J3/S8.104 

EXECUTIVE SUMMARY 

Digital strongly opposes the adoption of the language described in S8.104, hereafter 
referred to as Fortran 8x, as a new FORTRAN standard. We have voiced our ob¬ 
jections on many occasions, both inside and outside the X3J3 FORTRAN standards 
committee. We believe that X3J3 has undertaken much too ambitious a program 
in attempting both to modernize and significantly enhance FORTRAN. As a result 
Fortran 8x lacks focus, is difficult to learn and teach, is difficult to implement, and 
is difficult to use. The economic impact on the FORTRAN user base is severely 
negative. 

Digital agrees that there is a need for a new standard. Advances in Software engi¬ 
neering and computer technology have outstripped FORTRAN 77 in many areas. 

We do not argue against the appropriateness of any one of the major areas of en¬ 
hancement in Fortran 8x for consideration by X3J3. We do argue that the committee 
has gone too far in generalizing almost every single feature and in introducing so 
many new features in a single revision of the FORTRAN standard. We have specific 
objections to many of the features, but our primary objection is at a much higher 
level. We object to the fact that Fortran 8x is a new language, or more precisely, a 
new language unevenly glued on to an existing language. It is pointless to debate the 
merits of individual features when\ve believe that the whole approach—evolution by 
replacement—is so fundamentally unsound. 

Because Digital does believe that a revision to FORTRAN 77 is necessary, but 
that Fortran 8x is seriously off track, we support some variation on two proposals 
made during discussions of Fortran 8x. The first is the proposal by Dick Weaver, 
the X3J3 representative from IBM, that FORTRAN standardization be separated 
into two charters, one to develop a more modest revision to FORTRAN 77 and 
another to continue the more ambitious job of modernizing FORTRAN represented 
by Fortran 8x. The second is the proposal by Thomas M. Lahey ("The Fortran 8x 
Standard", FORTRAN FORUM, Volume 6, Number 3, December 1987) that the 
FORTRAN standardization committee(s) should have a publicly reviewed charter that 
clearly spells out the ground rules for standardization. We believe that the negative 
economic impact of Fortran 8x is such that, if the above proposals are not adopted, 
it is imperative at least that Fortran 8x not supersede FORTRAN 77, but exist as an 
alternative language standard. 


1 GENERAL OVERVIEW 

Digital affirms that a revised FORTRAN standard is long overdue, and we recognize 
the intention of the ANSI FORTRAN Standards Committee (X3J3) to standardize 
many worthwhile new language capabilities. We believe that the Fortran 8x language, 
as described in X3J3/S8.104, is a consistently defined language that would be imple- 
mentable, at least in theory. However, we believe adoption of the S8.104 draft would 
necessitate radical and untested changes from existing practice in the use and imple¬ 
mentation of the FORTRAN language. Further, we feel that such a departure from 
common practice is non-conformant with the charter of the X3J3 ANSI Standards 
Committee. 

Digital believes that approval of the proposed draft of S8.104 as a national standard 
for the FORTRAN language would not be in the best interest of FORTRAN users. 

We do not believe that the language defined in S8.104 will enjoy widespread accep¬ 
tance in the FORTRAN user community. We believe that vendors will be slow to 
implement the full language, both because of the complexity of the language and 
because of the questionable market. We believe that early implementations are likely 
to be slow and prone to bugs as vendors learn to deal with concepts completely 
new T to FORTRAN, and we expect a long transition period when large numbers of 
interpretations are necessary as vendors discover unexpected interactions among 
features. 

The result will be reduced portability' of programs because of subset implementations 
and conflicting interpretations of the standard. 

Digital recognizes that years of hard work have gone into producing the current draft, 
and that it would be difficult to shelve work that any particular individual has invested 
a lot of effort in. Nevertheless we urge X3J3 to withdraw the current proposal and 
consider a more evolutionary approach to modernizing FORTRAN 77. X3J3 should 
concentrate on standardizing existing practice and perhaps introducing a single major 
area of extension, such as array processing or language extensibility. This would 
permit a much better understanding of language interaction, compatibility', and 
implementability, as w'ell as faster adoption and implementation. If work on Fortran 
8x continues, it belongs wath a new technical committee w'hose charter is more in line 
with the ambitious goals of Fortran 8x. 


2 COST VS. BENEFIT 

The FORTRAN language has enjoyed considerable success despite the fact that 
it is more than 30 years old and that computer science and computer technology 
have evolved enormously during that time. The primary reasons for its success 
have been portability', performance, existing software, familiarity, and ease of use. 
None of these success factors is particularly inherent to FORTRAN, nor are they 
independent; rather they have developed over time. The fact is that there is a huge 
investment in FORTRAN software, in training for FORTRAN users, and in technology 
for implementing FORTRAN development systems. Fortran 8x puts this investment 
in jeopardy. 
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Fortran 8x attempts to improve FORTRAN in some areas where it has been success¬ 
ful, namely portability and ease of use. In addition it attempts to modernize the 
language to address software engineering areas where FORTRAN 77 is weak, such 
as reliability- and maintainability of complex software systems. We claim that these 
attempts to improve and modernize FORTRAN fall considerably short of their goals, 
and that their costs do not justify their benefits. 

The following sections describe the costs and benefits in more detail. 


2.1 Fortran 8x jeopardizes investment In user training 

Fortran 8x is a larger language than FORTRAN 77 and has a very different flavor. 
There has been much debate about how much larger Fortran 8x is and about how 
complex it actually is, based on statement counts, keyword counts, grammar rule 
counts, etc. Such quantitative arguments miss the point that Fortran 8x is qualita¬ 
tively much different from FORTRAN 77. Using the new language requires new 
methods of software engineering (e.g., MODULES/USE, user defined data types 
and operators), new ways of expressing algorithms (e.g., array extensions, numerical 
precision specification), and new language syntax (e.g., control constructs, attribute 
declarations). Differences permeate all aspects of the language; for example, array 
extensions and user defined types each require extensions to the semantics of assign¬ 
ment statements, I/O statements, and existing declaration statements, even though 
these are not themselves new language statements. 

Users will need to invest large amounts of time and money in retraining FORTRAN 
programmers and revamping FORTRAN curricula. Effective use of Fortran 8x re¬ 
quires new' methodological training, not just updating users on new syntax. The 
emphasis is on replacing existing practice with something better, not in building on 
the existing foundation. 

FORTRAN users face an additional problem in that they have to leam both the old 
"inferior' w'ay of doing things and the new'er way. This is because of the large body 
of existing code that must be maintained. It is impractical to assume that all this code 
could be converted to the Fortran 8x preferred style, but it is equally impractical to 
think that programmers would constrain themselves to FORTRAN 77 once Fortran 8x 
is available. The result is that improved language features are going to be mixed with 
the features that they are designed to replace for a long time to come. Maintained of 
FORTRAN code will have to know all the features and how they interact. 

2.2 Fortran 8x endangers investment in existing software 

Fortran 8x endangers investment in existing software in three aspects: compatibility, 
performance, and reliability. 

S8.104 states that no FORTRAN 77 language features are being removed from 
Fortran 8x and that standard conforming FORTRAN 77 programs continue to be 
standard conforming Fortran 8x programs. Even if these statements turn out to be 
true—and we believe that there wall be many problematical areas once full-scale 
implementations get underway—they only address part of the compatibility' problem. 
They make it possible for a user to continue to use an old FORTRAN 77 development 


system for programs that use only the FORTRAN 77 subset. The way FORTRAN is 
used in practice reveals more serious compatibility issues. 

First of all, there is the problem of how r w'ell the incremental features w'ork with 
the core and decremental features. The X3J3 language design strategy focuses first 
on specifying a new' capability, then on worrying about how’ it fits onto the existing 
language. Many interactions have been found and clarified through the iterations of 
the draft, but it is reasonable to suppose that many more will remain uninterpreted 
given the volume and pervasiveness of the extensions. Users will be in for surprises 
as they attempt to use new features and run into differences of interpretation or 
outright errors that affect their old code. For example, w'hat is the level of confidence 
that all the interactions have been worked out between FORTRAN 77 forms of storage 
allocation and association, such as SAVE, COMMON, and EQUIVALENCE, and new 
forms of allocation and aliasing, such a9 allocatable arrays, recursion, IDENTIFY, 
RANGE, and rename-lists in the USE statement. 

Second, there is the problem of compatibility with de facto standards that are in 
fact non-conforming FORTRAN 77, such as parts of MIL-STD 1753. Since X3J3 did 
not in general take existing extensions as a starting point, there is the danger that 
compilers will no longer be able to support these extensions w'here they conflict with 
Fortran 8x, and that the interaction of these extensions with Fortran 8x will vary from 
implementation to implementation. Specific examples of common extensions that 
w'ere not standardized include DO WHILE, INCLUDE, bit manipulation functions, 
and the *n notation for integer and floating point declarations. X3J3 cannot ignore 
the widespread use of these features, especially considering the length of time 
between revisions. 

Third is the problem of system compatibility. X3J3 only has to worry about language 
compatibility. Users also have to worry about the tools that they use to process pro¬ 
grams and the output of those tools. Fortran 8x is enough different from FORTRAN 
77 that it is likely that it will require new compilers, new' linkers and loaders, new 
library formats, and new runtime systems. It will likely be complicated and costly 
to use existing libraries with new'ly compiled Fortran 8x. For example, array features 
require that calling routines pass much more information about array arguments 
than FORTRAN 77 requires, thus requiring the passing of array descriptors ("dope 
vectors') instead of simple addresses. Compiled routines in existing libraries may 
not be set up to process this type of passing mechanism. A similar situation arose in 
FORTRAN 77 with passing character constants to library routines, and caused many 
problems. If character constant arguments caused problems for existing libraries—a 
new' language feature replacing a non-standard usage—one can imagine the problems 
that new passing mechanisms for array arguments would cause. 

The second area where Fortran 8x threatens the investment in existing code is 
performance. One example is the necessity' for array descriptors for array arguments 
described above. Even if compatibility problems are solved, new runtime overhead 
will be introduced for packing and unpacking the descriptors, even for programs that 
make no use whatsoever of new' features. 

Of more significance is the likelihood that the new features will not achieve the level 
of runtime performance that FORTRAN users are accustomed to, and that mixing 
new' and old constructs will slow down the old ones. One example is the use of array 
constructs on scalar machines. The semantics of array constructs are such that it is 
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often necessary to create temporary copies of the array. Vector machines can handle 
these in hardware or microcode, but they introduce significant overhead on scalar 
machines. Another example is that the use of explicit ranges and precisions for real 
variables may require the use of larger, but slower hardware data types than the user 
realizes. In general many of the new features inhibit compilers from optimizing or at 
least require considerably more analysis than compilers currently do; e.g., data object 
information (size, shape, type parameters) that is not known until runtime, recursion, 
runtime storage allocation, and runtime mapping of data objects. 

Finally, the adoption of Fortran 8x endangers the reliability of existing software. 
Vendors will have to produce new compilers or at least make major changes to 
every phase of existing compilers. Furthermore, it is likely that existing software will 
have to be recompiled to be compatible with new software. The risk of breaking 
existing programs is very high, whether from compiler errors or from differences 
in implementation specific details. Similarly users run the risk of incompletely 
understanding the implications of using new features with existing software. The 
situation is familiar to any user w’ho has ever switched compiler vendors or received 
a new and improved version of a vendor's compiler. Regardless of what benefits the 
new compiler provides, there are always some unexpected problems, and the greater 
the magnitude of changes, the more problems there are. 


2.3 Fortran 8x increases implementation costs 

The difference between Fortran 8x and FORTRAN 77 is at least an order of mag¬ 
nitude greater than the difference between FORTRAN 77 and FORTRAN 66. The 
major enhancements for FORTRAN 77 would hardly be noticeable if they w’ere being 
added to Fortran 8x. For example, FORTRAN 77 added one major new’ data type, 
and it was fairly constrained at that, namely the fixed length character data type. 
Fortran 8x on the other hand adds user defined data types, user defined operators, 
user specifiable floating point range and precision, use of arrays as data objects, array 
operations, and a variety of ways to parameterize all of these. Where FORTRAN 77 
added IF-THEN-ELSEIF-ENDIF, Fortran 8x adds CASE, new’ forms of DO loop, EXIT, 
and CYCLE. FORTRAN 77 added nothing comparable to Fortran 8x additions such 
as WHERE, RANGE, IDENTIFY, MODULE blocks, USE, interface blocks, optional 
and named arguments, internal procedures, attribute lists, or free source form. 

It is not just the number of new features or the difficulty of implementing any single 
feature that causes problems. It is the extent to which the new’ features pervade all 
aspects of the language: declarations, expressions, procedure interfaces, I/O, storage 
allocation, name space. The character data type in FORTRAN 77 was the only feature 
that had such repercussions, but Fortran 8x has arrays, user-defined data types, range 
and precision specification, and dependent compilation, any one of which introduces 
at least as much specification and implementation difficulty as the character data 
type. 

FORTRAN 77 did not require great advances in implementation technolog)’. Most of 
the new features were straightforward enhancements that could be added to existing 
compilers. This is not the case with Fortran 8x. Most of the features have never 
been implemented in commercial FORTRAN compilers and some of them have 
only been implemented experimentally in any compiler, if at all. Combined with the 
need to maintain compatibility with existing FORTRAN 77 programs, this means that 


much research will be required before complete Fortran 8x implementations appear. 
Even some relatively simple features, such as recursion, that already exist in many 
implementations, require careful design and significant implementation effort to add 
to implementations that are based on assumptions that conflict with such features. 

Despite the fact that FORTRAN 77 was a relatively modest extension to FORTRAN 
66, it still took several years for the first validated compilers to appear and several 
more years before the language achieved widespread acceptance. The situation will 
certainly be worse with Fortran 8x. Not only does Fortran 8x introduce many new’, 
complex, and untried features, but it also changes so many fundamental properties 
of the language that it is unlikely that existing compilers can be used as a base. 

The situation will be similar to that with other large new’ languages such as PLI or 
Ada. Early compilers will have to concentrate on just getting features to work, and 
not on code quality' or compile speed or additional programming tools. This will 
compound whatever performance problems are inherent. Early compilers will also 
be prone to bugs, both because of the magnitude of the implementation effort and 
the lack of experience and tests for the new features. 

2.4 Fortran 8x increases resource costs 

A previous section noted that in some cases Fortran 8x affects the runtime perfor¬ 
mance of existing software. This is just part of the overall resource cost. Fortran 8x 
contains new’ features that significantly increase compile-time costs and program size, 
as well as those that are extremely costly at execution time. Examples of features that 
increase compile time are operator and function overloading and the module facility. 
One need only compare the compilation speed of Ada compilers to get an idea of 
the cost. Extra compile time is also required for the extra analysis that must be done 
to generate good code for array operations, user-defined data types, and new’ control 
structures. 

The many features that Fortran 8x provides for the runtime parameterization of data 
types—assumed types, assumed range and precision, assumed size arrays, assumed 
length character strings—all increase program size. The compiler must generate code 
to fill in the information at runtime, and even worse, may have to generate multiple 
versions of the routines that contain the parameterized data objects, one for each 
possible hardware data type. The semantics of simple array operations may require 
the generation of temporary array copies particularly on scalar architectures that do 
not directly support vector operations; e.g., when assignments overlap or when the 
arrays in the body of a WHERE construct overlap the condition array. More complex 
array operations for dynamically mapping arrays or parts of arrays, such as RANGE 
and IDENTIFY, similarly may require temporary copies. 

The same features that increase program size generally also decrease program 
performance; e.g., data types that cannot be determined until runtime and array 
operations that require extensive use of temporaries. Many other features have been 
defined without regard to their implementability. Abstract data types make it difficult 
for compilers to exploit data types built into the hardware. The CASE statement is 
too general to allow’ for optimizing the dispatch to the individual cases. Dynamic 
allocation and dynamic aliasing make optimization much more difficult. 
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2.5 Fortran 8x hampers portability 

Fortran 8x fails to achieve its goal of increasing portability on several counts. First, 
there is the simple fact that the language is large and hard to implement. This will 
lead to subset implementations because of the length of time it takes to implement 
the full language and because the full language will be too large or too slow for some 
classes of machine. 

Second, there is the problem of practical portability of array features. Programmers 
will discover that certain uses of array features perform well on vector architectures, 
others on multiprocessors, and still others on scalar machines. Thus although 
programs written for one machine are nominally portable, they are not practically 
portable for performance reasons. The smaller the set of features for expressing the 
same semantics, the more likely it is that programs will perform well across a variety 
of architectures. Is the increase in expressiveness that the array features provide 
sufficient justification if they are not usable on certain classes of machines because of 
their performance? 

Third, there are features that solve one portability problem, but introduce another. 
The Fortran 8x features for numerical precision are an example. In theory they 
provide the numerical analyst complete control over the numerical properties of an 
algorithm if the range and precision of input and intermediate results are carefully 
chosen. Such programs can then be more easily ported than those in which a 
compiler chooses the a particular storage representation for real data types. In 
reality, the required range and precision for the real variables in a program may 
not be precisely known. What is known is that the binary storage representation 
on a particular machine is sufficient. The user thus needs a way to guarantee that 
a program uses an equal or larger representation when it is ported to a different 
machine. The Fortran 8x features, rather than practically improving portability, will 
just cause programmers to learn the right codes for forcing a particular hardware data 
type, just as PL/I programmers use FLOAT BINARY 24 as code for a 32 bit floating 
point number on a certain architecture. 


2.6 Fortran 8x does not increase maintainability or reliability 

Fortran 8x provides replacements for many FORTRAN 77 features. For example, 
MODULE blocks replace the use of COMMON for global data, USE replaces the 
non-standard INCLUDE, general precision and range specification replace DOUBLE 
PRECISION, USE with renaming and IDENTIFY replace the aliasing capability of 
EQUIVALENCE. Fortran 8x also provides new source form, new DO loop syntax, and 
new declaration syntax. These are a few of the many redundant features added to 
improve the style of FORTRAN programs. Finally, Fortran 8x attempts to encourage 
the use of the improved features, rather than the old ones that they replace, by 
relegating certain older features to a decremented features appendix with the threat 
of possible deletion in a future revision of the standard. 

Despite these attempts to improve maintainability and reliability, FORTRAN 8X will 
be less maintainable than FORTRAN 77. First, the old features will not disappear 
from existing programs; they will coexist. The new language will be larger, with more 
redundancy and more feature interactions than FORTRAN 77. Only programs wTitten 
entirely from scratch in Fortran 8x would benefit from the improved maintainability 


of the replacement features, and then only if programmers are careful to follow' the 
Fortran 8x style recommendations. 

Second, Fortran 8x introduces many new maintainability problems of its own. IDEN¬ 
TIFY provides dynamic aliasing that makes it difficult to determine the global effects 
of local modification of an element. The RANGE facility allows the scope of w’hole 
array operations to vary dynamically. User defined operators allow arbitrary side 
effects in simple expressions, which can lead to particularly subtle problems w’hen 
one of the standard operators is overloaded. Name space management and scoping 
are much more complex in Fortran 8x than in FORTRAN 77 because of the MOD¬ 
ULE facility, USE, internal procedures. This provides additional flexibility, but also 
additional opportunity for inadvertent aliasing. 

Third, Fortran 8x is less readable than FORTRAN 77 in one major area w'here 
FORTRAN 77 w*as already weak. The Fortran 8x declaration syntax is even more 
baroque than FORTRAN 77. The FORTRAN 77 attribute oriented declaration model 
is extended to allow lists of attributes. The attributes are separated by commas and 
are delimited from the entities by a double colon. There are a lot of new attributes. 
This syntax in itself is unwieldy, but it is complicated by the fact that complete 
information about an attribute may be contained in both the attribute list and with the 
defined entity. For example an initial value is assigned by putting the DATA attribute 
in the attribute list and the value with the entity, type parameters in the attribute 
list such as array bounds or character length can be overridden in the entity list. In 
addition the traditional FORTRAN practice of declaring attributes across multiple 
statements is retained and new r statements are added for most of the new' attributes. 
The attributes declared in FUNCTION statements use a different syntax. The new 
attribute list notation thus does not really solve the problem it addresses. 


3 MORE DETAILED ANALYSIS 

Detailed analysis of individual sections of Fortran 8x w'ould require volumes and does 
not seem worthwhile, given our strong disagreement with the overall philosophy of 
Fortran 8x. We believe that each major feature needs to be analyzed thoroughly for 
its impact on the language as a whole and on existing programs. The only way that 
the necessary analysis is practical is first to reduce the total number of new T features. 
As it stands now the new features are so interrelated that it is impossible to address 
one completely without pursuing its impact through all the others, and it becomes 
impossible to understand the overall impact. 

To give a flavor of Digital's objections, w r e provide more detailed comments on 
several sections: 


Array operations: the generality of the proposed features wall in many cases 
prevent compilers from generating high performance code on scalar, parallel, or 
vector machines, not only for new features, but even for programs that don't use 
new features at all. 
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• Portability of numerical software: these features are untested in practice, nor 
do they offer a preferable solution to the REAL and DOUBLE PRECISION 
declarations in the FORTRAN 77 language. 

• Language extensibility: these features provide syntactical flexibility, but no 
semantic improvement, since they do not provide an opportunity for the ex¬ 
ploitation of available hardware capabilities. 


Deprecated features :the features chosen for deprecation are not justifiable on 
the basis of potential cost and benefit. 


These problems are detailed below. 


3.1 Array Operations 

For array operations, the Fortran 8x language proposes many new and complicated 
features, intended to provide more concise and expressible mechanisms for the 
specification of array-valued operations. These new features extend the support 
given by FORTRAN 77 for arithmetic, logical, and character operations with respect 
to arrays. The draft Fortran 8x standard includes: 

• Array notational syntax, allowing for operations on w'hole arrays, and contiguous 
and non- contiguous array sections. 

• User-supplied array-valued functions are allowed, assuming whole arrays and 
contiguous or non-contiguous array sections as parameters. 

• With the RANGE feature, the caller program passes a ranged array to a called 
program, w'herein the range may be changed globally; the range is then returned 
to the caller. 

• The IDENTIFY statement allows a subset of an array, especially a multidimen¬ 
sional array, to be mapped by a linear mapping function, for reference from a 
single dimension. For example, a diagonal element of a square matrix could be 
referred to as a unidimensional entity. 

• ALLOCATABLE arrays have no memory allocated to them, until that memory is 
•allocated explicitly from storage, specified as heap, not stack (both are possible), 

storage in the Fortran 8x draft. 

• Intrinsic functions construct and transform arrays, to perform scatter/gather 
operations, and to support expanded computational capabilities for arrays. 

In addition, characteristics of arrays may be specified, such as <assume-shnpe, 
assume-size, explicit-shape, alias >, to determine shape and contiguity; the specifica¬ 
tion of such attributes influences array conformance with respect to other arrays. 
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The proposed Fortran 8x array features were designed for supercomputer users, at a 
time when an array syntax notation was thought necessary to allow* the exploitation 
of vector processing from FORTRAN programs. The Fortran 8x array syntax notation 
also is intended to provide a convenient means for coding array-intensive algorithms. 
Since the original work on array features was conducted by X3J3, compiler techniques 
have been developed where automatic vectorization has become a viable approach 
that avoids the need to revise the language definition. Thus, the new syntax notation 
for manipulating arrays is no longer necessary for exploiting the capabilities of vector 
processing hardware. Although it is true that an array syntax notation might well be 
convenient for programmers of array-intensive applications. Digital does not find that 
such expedience is reasonably sufficient to justify enlarging the language in this way, 
especially since execution speed of existing programs wall be degraded. 

Were the proposed 8x array features to be added to the FORTRAN language, in order 
to generate scalar code of performance comparable to FORTRAN 77, the analysis for 
dependencies that would be required w*ould be at least as extensive as for automatic 
vectorization. The Fortran 8x constructs require excessive loop overhead on scalar 
machines, since loop dependencies would have to be exposed to generate high 
performance scalar code. That is, Fortran 8x constructs will execute more slowly than 
equivalent FORTRAN 77 code on scalar machines, where no dependence analysis is 
done. 

Furthermore, array features imply a different programming style, w*here multiple 
array operations that are merged into a single DO-loop in programs for scalar ma¬ 
chines, are expressed as a series of w'hole array operations. In order to maintain 
the present efficiency of FORTRAN 77 algorithms for processing in Fortran 8x, vec¬ 
torizing compilers would have to do dependence analysis to perform correct loop 
merging of scalar code. Thus, FORTRAN 77 constructs will execute more slowly than 
before in the presence of FORTRAN 8x capabilities. 

Dummy argument array references, which assume that the caller program is passing 
non-contiguous arrays, w’ould be most problematic. The discontiguity of these arrays 
disallow's passing by direct address, and, in fact, imposes a compiler requirement 
that all arrays be passed by descriptor; i.e., a structure with information about the 
characteristics of the array, such as size and data type of elements, dimensions 
and extents, and addressing algorithm. All actual parameters which are arrays 
would necessarily be passed by descriptor, since all formal parameters which are 
arrays must be accepted by descriptor, so as to handle non-contiguous arrays. In 
many FORTRAN compilers, arrays are passed by reference; the technical solution 
for maintaining semantic consistency for such code would be likely to result in a 
degradation of execution speed. 

The costs associated wnth the inclusion of the Fortran 8x array features w'ould be 
borne by vendor and user alike, in the form of development and testing, heavy 
training and maintenance costs, and degraded code execution. Finally, there is a lost 
opportunity cost in that the attention given to the proposed array features diverts the 
interest of researchers and vendors from striving tow*ard automatic technologies to 
accommodate advances in hardware development. 
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3.2 Numerical Portability 

Most FORTRAN users have large numbers of computational programs, which have 
been devised for use on various machines with different word sizes. The Fortran 
8x language proposes the addition of the PRECISION and EXPONENT_RANGE 
attributes w’hich are intended to provide improved portability among processors with 
different word sizes. The PRECISION and EXPONENT.RANGE attributes allow’ the 
user to specify a range and precision for a given allocated quantity of type REAL or 
COMPLEX. Also, the Fortran 8x language provides some intrinsic functions that are 
designed to work within this numerical model. 


Digital, IBM, and many other vendors allow’ the '*n' notation (e.g., "REALM", 
'COMPLEX*16"). Although it lacks a well-defined model of floating point com¬ 
putation and a detailed definition for precision and exponent range requirements, 
the "*n" notational syntax retains consistent numerical behavior from one machine 
to another. Because of the "fixed" nature of the REAL and DOUBLE PRECISION 
declarations in Fortran 77, the programmer can be certain of the range and precision 
of the computation that the program performs. For example, the following program, 

REAL A 

DOUBLE PRECISION B,C 
READ (5, *) A, B 
C = A + B 
WRITE (6, *) C 
END 

when compiled on a given machine, uses a particular representation with a known 
range and precision for A, and a different particular representation with a greater 
precision for B, C, and the temporary result of the expression "A + B." 

Although these particular representations differ on CPUs from different vendors, 
there is one certainty: if a program gives correct results on a given machine, without 
generating underflow or overflow conditions, then the program could not possibly 
have required greater range or precision than was used in its computation. For 
example, if a simulation program gives a correct answ’er, without generating overflow 
conditions, using DOUBLE PRECISION on an IBM 3090, then that computation 
did not require more than 15 decimal digits of precision or an exponent range 
greater than 10**+ -75. When the simulation program is brought to a VAX, with a 
precision and exponent range using the VAX G.floating data type, the results will be 
comparable, and extensive numerical analysis generally will not be necessary. 


In Fortran 8x, the definition of the attributes, "PRECISION«p" and 'EXPONENT. 
RANGE «r,' mandates that the processor use a representation to guarantee a mini¬ 
mum of p decimal digits of precision and an exponent range of at least 10** +-r w’hen 
allocating storage for this quantity. Generally, the processor selects a representation 
with greater precision and range. Thus, the user no longer has any knowledge of the 
precision and range that the program actually requires in order to deliver a correct 
result on a particular machine. 


For a working program that is ported from one machine to another, therefore, 
incorrect results may be obtained. For an IBM 3090, if a PRECISION “7 is specified 
for the program's variables, a representation that provides 15 digits of precision 
(REAL*8) will be used. So, although the program obtains correct results on the IBM 
system, it may not yield useful results when ported to a VAX, w’here a specification 
of PRECISION*7 provides 7 decimal digits of precision (F.Floating). 

The rules for expression handling in Fortran 8x require that arithmetic operations, 
such as +, -, *, /, and **, that return results maximize both the precision and range 
of two operands simultaneously. For example, in the following program, 

REAL (PRECISION=15, EXPONENT_RANGE=50) A 

REAL (PRECISION=16, EXPONENT_RANGE=35) B 

C = A + B 

precision is 16 and exponent range is 50 for "A + B.” On a VAX, this combination 
can be delivered only with the REAL* 16 type, although this specification never wa9 
explicitly declared. 

Thus, the proposed Fortran 8x language, on the issue of numerical portability, 
makes no guarantee that programs which are ported, w’here the PRECISION and 
EXPONENT.RANGE attributes are used, produce acceptable results, since data rep¬ 
resentation is a non-portable aspect of this language feature. Further, while DATA 
and assignment statements are consistently represented from source code represen¬ 
tation on one machine to source code representation on another machine, results 
generated from these declarations w’ould again differ from machine implementation 
to machine implementation. Although Digital believes that this Fortran 8x feature 
achieves an increase in program portability, this aspect of the Fortran 8x language 
exposes an area of unportability that has not yet before been encountered. Digital 
further believes that programmers will learn to avoid this problem by using range 
and precision specifications that force a particular hardware data type to be used 
without regard to the actual numerical properties of their algorithms. 

3.3 Language Extensibility 

The motivation for many of the proposed Fortran 8x features associated with lan¬ 
guage extensibility is improved notational convenience, especially for the expression 
of algorithms in numeric and scientific computations. These features include: MOD¬ 
ULE/USE, module procedures, derived and parameterized data types, user-defined 
operators, operator overloading, user-defined generic functions, as well as others. 

MODULE/USE and module procedures are an attempt to package data definitions 
and procedures to manipulate them. The addition of MODULE to FORTRAN 
requires a program library capability, able to generate multiple versions and to 
maintain name spaces, to provide a FORTRAN programming environment. Under 
FORTRAN 77, a subroutine may be compiled independently from a main program 
unit. In Fortran 8x, the environment of the subroutine-that is, all the other caller and 
called programs relevant to the subroutine-must be made know r n to the compiler at 
the time of compilation. Support for dependent compilation implies a significant 
increase in compiler complexity, and in this scheme, may increase costs of providing 
other components of system software, such as linkers. Digital does not agree that 
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users would reap a major cost/performance benefit from the inclusion of this feature 
in standard FORTRAN. 

Derived types allow new specification methods for many data structures commonly 
in use by FORTRAN programmers. Since derived types are not intrinsic to the 
language, they cannot exploit hardware capabilities for pointer, bit, and character 
string manipulation. Parameterized types permit flexibility in the specification of 
record structures, transferring the chore of name space management from the user to 
the compiler, but adding a level of complexity with respect to code maintenance to 
challenge the user. 

User-defined operators permit tokens to appear as part of the language; FOO(X) may 
be specified as .FOO.X. The addition of this Fortran 8x feature would not result in a 
benefit to performance, and may, in fact, increase compiler complexity and compila¬ 
tion time, since the underlying support indicates simple function calls. Overloaded 
operators allow’ users to specify the contextual behavior of operators. With respect 
to FORTRAN, this technology is not proven, may be subject to error, w’ould restrict 
optimization, and generally, increases compiler complexity and compilation time. 


3.4 Deprecated Features 

The deprecation of features, that have become redundant by the inclusion of certain 
new features in the draft standard which attempt to supersede the FORTRAN 77 
functionality, is unwarranted. The list of deprecated features includes BLOCK DATA 
program unit, COMMON, ENTRY, EQUIVALENCE. FORTRAN users have made 
billion-dollar investments in FORTRAN 77 code that utilize some of these deprecated 
features. Since there are no cogent technical justifications for the removal of these 
features from the language, conversion costs to accommodate deprecation is not 
justifiable. Moreover, the indeterminate future of the deprecated features leaves the 
user with no way to predict whether the features will appear in a future version of the 
standard language. 


4 CONCLUSION 

Digital anticipates a negative impact on all users of the FORTRAN language, if 
the proposed draft standard, S8.104, is accepted as a revision of X3.9-1978-the 
FORTRAN 77 language. We strongly feel that the draft ignores or replaces existing 
practice that has become the de facto standard in the industry. Digital recommends 
that the X3J3/104.8 draft of Fortran 8x be reevaluated by X3J3, for resolution of 
the technical problems described in this paper or that X3J3 start over with a much 
reduced scope with the Fortran 8x w'ork assigned to a separate technical committee. 
We reiterate that X3J3 should pay much more attention to the impact of language 
standardization on existing code, tools, and knowiedge, and less on language design 
in the abstract. We do not believe that cosmetic changes to individual features 
will make Fortran 8x acceptable. At the same time we realize that some of our 
specific concerns would be manageable in the context of a smaller and more focused 
language. If the X3J3 Committee is unable to address this recommendation, Digital 
stresses that an alternative action should be the reconfirmation of FORTRAN 77, 
rather than superseding it at the time that Fortran 8x is approved. 
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RESULTS OF DIGITAL/CSSE'S FALL'87 DECUS QUESTIONNAIRE 


Pamela M. Blotcky 

DIGITAL EQUIPMENT CORP., CSSE/Languages and Tools 
February, 1988 


1 INTRODUCTION 

Customer Services Systems Engineering (CSSE) is an organization 
within DIGITAL whose purpose it is to ensure that DIGITAL's customer 
services organizations are prepared to support new products. One 
aspect of this job is to represent the needs of the customer services 
organizations, and the customers they serve, during the development 
cycle of new products. 

Feedback from customers is vital in performing this task. As one 
means of collecting this information, CSSE/Languages and Tools 
developed a questionnaire that was distributed (via the Languages and 
Tools SIG folder) to attendees at the last three DECUS symposia. 

This article describes the results of the Fall 1987 survey. 
These results have also been distributed to a number of organizations 
within DIGITAL. 51 of you took the time to respond to this survey, 
and we thank you very much for doing so. 

This questionnaire will be distributed at future DECUSes. 


2 PRODUCT-SPECIFIC CONCERNS 

We asked, "Is there any particular software product that CSSE 
should examine in order to resolve problems pertaining to product 
functionality, product quality, service offerings, or administrative 
problems (ordering, SDC, etc.) 

If so, please indicate the product,and describe the problem." 

As in previous surveys, there were some comments about MMS, 
particularly concerning difficulty in building the descriptor files. 
As for administrative problems, SPR response was mentioned. 


3 DOCUMENTATION 

We asked if you have experienced problems with documentation. 
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You told us that indices could be better, The System Services 
manual should have more examples, and that there is a great deal of 
improvement between the V3 and V4 VMS documentation sets. 

The DATATREIVE manuals and the C RTL manual were criticized for 
organization, comments that also appeared in the Spring 1987 survey. 


4 VMS 


We asked the DECUS attendees to rate the quality of VMS, using the following 
scale: 

1 (excellent) 2 (good) 3 (fair) 4 (poor) 5 (unacceptable 

The results were as follows: 

1-26 responses 

2 - 19 responses 

3 - 2 responses 

There were no responses for categories 4 and 5. 


We asked "What kind of features would be of use for you to help you in 
maintaining your backup media library? 

The most popular request was for a tape librarian (8 responses). 3 people 
asked for an archiving system. These have also been the most popular features 
requested in surveys we've done at past DECUSes. 


5 SECURITY 


Responses to this section of the questionnaire were sent to the CSSE engineer 
concerned with security on VMS, and to the developers of SES/VMS (VMS Security 
Enhancement Service). 

The VMS Security Enhancement Service is a software security consulting package 
that provides many features of mandatory access controls, security auditing and 
labelled output for VMS. It provides your system administrator or system 
security officer with the software to devise a system-wide security policy that 
helps safeguard users' data and software from security threats. These controls 
do not replace standard VAX/VMS security features, but rather augment them with 
an additional mandatory access contol policy. Releases are numbered to 
correspond to the prerequisite VAX/VMS release. 
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Here are the questionnaire results: 

38 of you told us that you are using VMS security features. 

We also asked whether you felt that any security related features were 
missing in VMS. Here, we received many requests for encryption, includinq 
DECnet and Ethernet encryption. There were also requests for ACLs on queues 
selective alarm ACLS, and batch support at varying classifications. 

We asked "Which layered products are you using?" Fortran, VAX C, CDD, LSE, CMS 
MMS, DTR and FMS were the layered products most frequently used in secure' ' 
environments. This was also true in the survey's we did at the Spring '87 and 
Fall '86 DECUSes. You told us that you felt that security features in layered 
products were adequate. 


6 TRAINING 


We asked "Is there a course, not currently offered by DIGITAL, which you feel 
is badly needed? If so, please indicate the best medium for the course (CAI - 
computer-aided instruction; SPI - self-paced instruction; LEC/LAB - lecture/ 
lab). 

VAX SYSTEM MANAGMENT, PERFORMANCE MANAGEMENT (SPI), RDB, RDB INTERNALS 
(lecture/lab) and TPU PROGRAMMING (SPI) were among the most popular responses. 


7 SERVICE DELIVERY 

Out of 51 questionnaires, 5 indicated a problem with the delivery 
of products. A list of these comments has been sent to SDC 
management. 

Concerning telephone support, many of you provided comments, some 
of which pertained to specific products. These were forwarded to the 
telephone support center. 

Most of you felt that you are "sufficiently aware of DIGITAL'S 
software product offerings, their features and benefits, to develop 
solutions to your business needs." 

10 of you told us that DIGITAL salespeople and software 
specialists not been able to answer your questions, or promptly 
provide you with information, peraining to DIGITAL software products. 
Some of you indicated that you get this information from DECUS, 
tradeshows, or publications. 
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We asked "If you have utilized DEC'S consulting service, were you 
satisfied with the results?" 5 of you said "yes", 4 said "no". 

5 people had made use of DECstart, of which 4 reported that they 
were satisfied with the results. 


L&T Woods Meeting Notes 

The L&T SIG held its Woods Meeting at the Marriott Greenspoint in 
Houston, Texas on February 27 & 28. Attending were: 

Earl Cory - Symposium Rep/Vice Chair 
Al Folsom - Newsletter Editor 

Steve Jackson - Standards Activities Coordinator/PDP-11 Rep 

Mark Katz - Session Notes Editor 

Lisa Kerby-Rodgers - ADA Working Group Chair 

Mark Kidvell - CM Working Group Chair 

Celeste LaRock - Digital Counterpart 

Gary Lelvis - Alternate Symposium Rep/Session Coordinator 

Gerald Lester - Low Level Languages Working Group Chair 

Bruce Mebust - DIBOL Working Group Chair 

Joe Mulvey - Development Counterpart, PDP-11 Software 

Joe Pollizzi - Working Groups Coordinator & Campground Coordinator 

Dave Ream - Volunteers Coordinator 

George Scott - Clinic Director/Assistant Masters Program Coordinator 
Bob van Keuren - Wishlist Coordinator 
Sam Whidden - SIG Chair 
Jay Wiley - CommComm Rep 


Chief Scribe, Mark Kidvell, was responsible for ensuring that each 
segment was being recorded. He then compiled and edited the individual 
segments within two weeks. Individual recorders for each section 
are identified after the topic description in parenthesis. 


1. L&T support of PDP-11 layered products. (Earl Cory) 

There is concern within the L&T SIG leadership that the PDP-11 
interests lost focus when the CL SIG merged with L&T. Discussion could 
not pin point whether or not this has occurred, but L&T wants to embrace 
the L&T concerns as they relate to the PDP-11 environment. One 
suggestion brought up repeatedly: We should get the PDP-11 related SIGS 
involved with us. Our roadmaps should list any language/tool related 
topics sponsored by the other SIGs, as well as the other SIGs mentioning 
L&T sponsored sessions which may affect their members. Joe will see 
about inviting the other SIG Chairs to send representatives to L&T's 
Working Group Leaders meeting. 

Sam noted that the PDP-11 group does not want to be a SIG and sponsor 
sessions. It may desire to sponsor sessions in the future partially via 
the L&T SIG. Part of the reason lies in the fact that there are already 
four "PDP-11 SIGS" - RSX, IAS, RSTS, and RT. 


Earl mentioned that the Cincinnati L&T has 100 "VAX" sessions, 13 
"PDP", and 22 sessions which would be applicable to either. Earl also 
mentioned that the Anaheim symposium (Fall 1988) has a "session Czar" to 
call attention to sessions that are duplicated by different SIGs. 

2. Newsletter content and volume, acquisition of material: (Jay Wiley) 

Need to put some items annually into the SIG Newsletters. Suggested 
items: 

SIG Charter 

Working Group Descriptions, contact information 
Masters List 


Need to encourage DEC to submit. Some of the best newsletter input 
comes from DEC. Another suggestion - some SPRs could be a good source 
for the SIG Newsletter. SIG could convert to newsletter format. 

Idea: Have a Hints and Kinks section of the newsletter. Stated need 
of an editor for it. Mark Katz volunteered. 

Each Working Group Chair should have a columnist for newsletter input 
(if not the WG Chair themselves). 

Final idea offered - often times speakers are unable to get their 
sessions into the Proceedings. Ask for session transcription help on 
the volunteer form. Start getting some of the sessions into the 
newsletter. 

Some time spent discussing the page limits and lead time on the SIG 
Newsletters. Discussed how the page limits are set by the combination 
of postal expense and past history. One alternative Jay Wiley reported 
that was being looked at was having a professional organization out of 
Colorado handle the newsletters . This may relieve some of the postage 
expense pressure as the rates you could expect would be postal zone 4 
rates rather than postal zone 7. Having a professional organization do 
the Newsletters may also reduce some of the lead time involved (ie. from 
time of submitted article to actual print date). 

3. Anaheim Reports: (Mark Kidvell) 

Anything extraordinary we should know about: 

Newsletter and its problem being looked at. Newsletter subscriptions 
are not "renewed" - a new subscription is given. If someone checked "I 
want SIGNEVS" at both symposia, you get 2 (TWO!!) subscriptions. When 
checking with subscribers, they are basically happy with what they got. 
Therefore, CommComm is looking at doing a cross correlation on trying to 
find out who used to subscribe and who isn't currently and then trying 
to contact DECUS members who let their subscriptions expire. Another 
detail brought up was the need for standard electronic submission format 
for the newsletter. 
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4. Symposium Rep: (Bruce Mebust) 

L&T is pushing hard at the number of session hours allocated by the 
Symposium Committee. We get additional resources at each symposium but 
only slowly. 

To make the best use of the available resouces, CFPs should be 
reviewed to eliminate duplicates, combine some or make panels of some. 
Perhaps sessions can be expanded from 45 minutes to one hour. 

Volunteers are needed (a "Stream Team”) to do this culling between 
the end of the CFP period and session scheduling. Although it is 
sometimes difficult to judge the level of a session, the group can also 
try to make sure that introductory sessions get scheduled before advanced 
sessions and clarify vague abstracts. The team can also suggest 
streaming strategies to Earl. 

Sam will try to get the Stream Team a meeting to do the streaming 
for the Fall 88 symposium. Abstracts will be printed and mailed by Sam 
to the team. CFP closing is May 29. Final abstracts will be out on June 

11. Scheduling will occur on June 25. The "Stream Team" will meet on 
June 11 in New England. The team will consist of Joe Mulvey, Steve 
Jackson, Celeste LaRock, Lisa Kerby-Rodgers, Earl Cory, and Joe Pollizzi. 

CFPs for Fall 88 will be turned on at DCS on March 3, 1988. 

5. SIG Tape: (Gerald Lester) 

A new L&T tape should be ready by the end of March. 

New contents include: 

1) Updated TEX and LATEX 

2) X-windows Vll.O 

3) GNUemacs 

4) C++ (for UNIX) 

6. Cincinnati Planning and Logistics: (Gerald Lester) 

A problem that has shown up in in the past is an individual 
monopolizing equipment in the campground. Suggestion: Have a time 
restriction. 

The skit is being done by DEC AI with a warm up by Kurt. 

The campground is smaller than Anaheim but consists of 3 SMALL rooms, 

1 medium room, and a LARGE hall. The layout is not available since 
the campground is still in the pre-planning phase. The steering 
committee felt, with the exception of having APL, the APL character 
set (font?), and an APL keyboard all on the SAME machine, the 
equipment was sufficient. It was also felt that an LN03 was needed. 

Terry will be in charge of setting up the room (S240) at 0900 hrs on 
Sunday. 


The suite will be in the Omni/Netherlands hotel. Both the campground 
and the suite will be shared with UNISIG and AISIG. 

DECUS will be holding a press day on Monday with the press free to 
attend sessions Monday afternoon and evening. 

UPDATE.DAILY will spotlight security. Articles were stated as being 
due in late April. Some suggestions were made as to how to offload 
the UPDATE.DAILY machine so that response will be better. 

The developers' schedules will be posted in the campground, the booth, 
and in the suite. It was also suggested that the ANSI reps' schedules 
also be posted. The Clinic will be "combined” and shortened to 
two (2) hours. 

Joe P. will be handling Language Wars. 

It was felt that the L&T wizard session at Anaheim "degenerated". 

The following suggestions were made as to how to avoid a repeat of 
that occurrence and otherwise improve the session: 

1) Have "Plants" go first 

2) Give Vizard Vidgets 

3) Screen presenters 

4) Have a "strong" chair 

It was also suggested that we have a "collage" of wingers to fill 
in when we get a no show for a speaker. The issue was considered of 

being able to check with registration on if speakers ever 
picked up their badges. 

Store items: 

In Cincinnati we will be selling: 

1) Small Planners 

2) Improved VAXpads (Celeste will have developers proofread) 

3) A Screen Clean Chamois 

It was suggested that in the future we offer update service for 
the VAXpad and that we remove times (just pre 0800 hrs) from the 
planner. 

7. Session Quality Control: (Dave Ream) 

Mark Katz passed out two collections of statistics from the session 
evaluation cards: one with and one without comments. 

Many comments note the importance of having the session content match 
the abstract. Can comments be sent to the Speakers? Celeste will 
distribute to the DEC speakers. For Anaheim some distribution will be 
attempted via the Working Group Chairs. Mark Katz will supply an 
address list for this purpose. Future symposia will provide a box in 
the campground for speakers to deposit a self-addressed stamped envelope 
for evaluation returns. 
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Other comments requested more handouts. SIG policy is of only having 
handouts for DEC product release information that can't be placed in the 
session notes. 

Collection of evaluations cards was down from Nashville. Reasons 
were given as: cleaning staff trashing them too fast at the end of the 
day and too many exits. Sam vill provide colored paper signs to put on 
the boxes noting the purpose and permanency of the boxes. 

Session Evaluation Cards should not be pushed at SIG interface 

sessions, except for those such as Q&A. 

The "back” of the card containing speaker and chair information 
should be copied and sent to the Volunteers Coordinator. 

Mark is overworked with the extra data being collected on the cards. 
George Scott offered to take over the evaluation process and vill work 
with Gary Lelvis on coordination. Mark vill still handle vhat appears 
on the card and getting it printed. 

Only half the speaker evaluation forms were turned in and the results 
have not been distributed to the SIG yet. The idea of mini-GIB 
locations (giblets?) was mentioned to assist in collection of forms for 
symposia with multiple buildings 


8. Anaheim-88 Planning & Logistics: (A1 Folsom) 

9. Counterparts' Reports: (A1 Folsom) 

10. Session BOFs: (Gary Lelvis) 

Q&A time is lost with only having 45 minute sessions. For important 

sessions VG chairs should schedule a BOF with Earl. Have the speaker 
announce the BOF room & time. Ve could do one BOF for a stream. DEC 
presentors and attendees are also frustrated about the Q&A cutoff - this 
period of time often provides the best feedback on Digital products. Ve 
are also in agreement that the Q&A period is an important part of the 
session tape. 

On the DEC frustration - Earl feels DEC presentations tend to last 
a full 45 minutes, sometimes approaching an hour. Celeste requested that 
ve go back to full hour sessions, especially for DEC sessions after 
Cincinnati. 

Speakers/chairs vill be responsible for announcing the upcoming 
BOF associated with the session. Ve need to keep track of dead spaces 
(ie. cancellations) and reschedule them to use effectively as BOF 
sessions. Earl is in charge of the BOF scheduling, but Mitch Brown 
vill assist. A1 vill announce these nev innovations in the newsletter. 


BOFs now need session chairs independent of speakers. Commercialism 
during BOFs has become an issue. Gary vill handle getting the session 
chairs on the fly with Dave Ream's help. Ve need to make sure the chair's 
company does not equal the speaker's company. There is also the concern 
about inexperienced chairs not being able to handle situations such as 
blatant commercialism. 

11. Increased L&T emphasis on development methodologies: (Dave Ream) 

Sam reiterated the need to stress connectivity and products other 
than Tools and Languages. People should be encouraged to give sessions 
on "hov to do" approaches. 

The "stream teams" should address these areas as veil. 

12. Management of Vorking Groups, Vorking Group contributions: (Mark 
Katz) 

Joe indicated a definite "lack" in the commercial languages areas. 

Is this a downturn in the CL area or do ve need to attract more 
attention somehow? It may be that there are no pressing issues in these 
languages. 

As interest goes avay, a void is created by a disappearing VG. At the 
same time ve do not want a vorking group just for the sake of its 
existence. Mark Kidvell pointed out that both Tools and Methodologies 
are veil covered and right now have no indication of any difficulty, but 
the problem lies in the sheer number of languages. 

Lisa Kerby-Rodgers suggested BOFs for "orphan Languages" and if 
people are really interested then a real vorking group might be formed. 
Lots of agreement on this comment. 

In the meantime, Bruce Mebust vill act as a Vorking Group Facilitator 
for any query/activity that falls within the L&T SIG interests and are 
not covered by a Vorking Group or specific L&T position. 

Certain Vorking Groups are sending out newsletters to VG members. 

These newsletters need to be copied to both Joe and Al. 

DEC counterparts/liaisons for the vorking groups in some cases did not 
attend the vorking group meetings because of a lack of communication. Ve 
need to improve this. 

L&T vill provide Vorking Group specific business cards for the Chairs 
and are to be placed in the campground. 

L&T vorking group meetings (vill not be taped). Vorking group chairs 
should sign and turn in the form to refuse audio taping. 

13. Vingers: (Celeste LaRock) 
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Wingers are those people who literally save a session by "winging it 
when the original speaker doesn't show up". Although several scenarios 
were brought up and discussed, the general consensus within the L&T 
leadership is that we have handled the situation quite adequately 
(although it may be luck) and therefore there should be no change in the 
way things are currently done. We should, however, keep watch over the 
situation to come up with ideas, adjustments. 

14. Session Notes Reorganization: (Steve Jackson) 

Discussion centered on the desire to integrate the technical and 
commercial sessions. There seems to be no convenient way to break them 
into days. It was suggested to separate the manuals into non-contiguous 
days. The most popular suggestion is to have 4 books: 

Monday, 

Tuesday, 

Wednesday, and 
Thursday and Friday. 

Mark Katz stated there should be more session notes for Cincinnati 
than Anaheim with more DEC submissions than ever. Additional discussion 
centered on the page counts which, like the SIG Newsletters are based on 
previous history. The question was raised that how can we get adequate 
page count if we're restricted by symposia 4 or 5 years ago. The 
algorithm needs to consider the number of sessions involved and possibly 
the percentage of people who submit sessions. 

Mark Katz brought up that Digital sessions are often submitted 
without speaker names, so Mark doesn't know who will submit the session 
notes. Can the submitter field be used to identify who Mark should 
^contact for session notes. 

Gerald Lester requested that Mark Katz insert a bold notice between 
sessions to make it easier to tell where one stops and the other ends. 
Because of the white space involved, this is virtually impossible to 
expect it to be approved. After discussion, Mark stated that he would 
look at the possibility of having a header or footer for each page with 
the session identifier on it. 

15. Organization of Folder Editing timing and tasks (new job): 

This discussion was cancelled as the person who volunteered to 
be Folder Editor has withdrawn the offer. 

16. L&T Volunteer management: Volunteers & Masters Databases: (Bob Van 
Keuren) 

Dave Ream is constructing databases for volunteers and master. 

Sam Whidden sent him information, including feedback md survey forms. 
Sam made copies for Terry, Gary, and the working group chairs. 


Dave is thinking about the database design for the sheets. He sees 
two types of records: 

1. Persons: name, address, phone, areas of interest. 

2. Survey: for miscellaneous stuff. There are many questions, 

which we can boil down to just a few. It would be easy to 

metricize them, with comments. 

Dave will create reports for steering committee members. 

Dave asked how long we should keep survey information. Sam replied 
that survey stuff doesn't need to be preserved. Ve should maybe 
send it to others, such as in DECUS. You don't need to fill your 
garage with information. 

There is also a question how to file volunteer information. Maybe 
not in the database. What changes do we need? Some questions are 
'Who are you?' information. Maybe we should store the date of entry 
into the database. Indicate which symposia they go to—fall, spring, 
or 'I don't know.' 

Sam said we will budget if you want to send a form letter. He also 
mentioned that it is important to thank people who fill out a form. 

Ve can compile a list of various people: steering committee, session 
chairs, etc. 

Earl said he put in a tear-off sheet to send back. He wants to get 
feedback about taking names off the list. 

Joe Pollizzi suggested a generic letter about attendance. After we 
get one made, we can decide just how we are going to use it. Earl 
suggested just a little box to check off and return. Mark Katz 
suggested several little boxes. Earl added 'and a 22-cent stamp.' 

It was mentioned that a lot of people use the fact that they are doing 
something at DECUS as a way of getting to go to symposia. Give them 
some options to do something. 

Sam noted that we need help; ve need to spread the work load. 

Ve can add more people to the steering committee and give them 
whatever titles you like to get them to help. 

17. Cooperation with VAX SIG on Masters Directory: (Bob van Keuren) 

The VAX SIG talked is interested in doing a Masters list, but haven't 
yet. 

Ve would like to see the Masters concept used by many SIGs. The 
Steering Committee discussed whether ve could put "VAX Masters" on our 
list since the VAX SIG isn't doing it yet. Ve will ask the VAX SIG 

whether they would like us to try it as it may help to be a deciding 

factor for the VAX SIG (and others) if people use the VAX Masters. 

(Dena Shelton is the Masters Coordinator) 
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18. Nev Vishlist procedures & timing: (Lisa Kerby-Rodgers) 

The comment was raised that previously the vishlist had no real 
direction. General consensus is the desire to have the vishlist cycle 
start at one symposium and complete at the folloving symposium (vith the 

next cycle starting at the same time). Some discussion centered on the 
balloting process: if placed into the nevsletters, the turnaround time 
is too great to expect DEC to have proper time to reviev and respond if 
ve vait to give them the vishlist items after the ballots are returned; 
if voted on at the symposium vhere brought up, then 80% of the 
DECUS membership is excluded for that cycle. Another point brought up 
is that only 20 - 30% of the DECUS membership subscribes to the SIG 
nevsletters (another problem). Final results of the discussion are: 

a. Working Groups need to be brought into the cycle - for both 

analysis of the need and for getting input for the vishlist. 

At least one VG Chair assigned vith each submission to keep 
track of and provide clarification/input for DEC. 

b. Preliminary "balloting" done at symposia (by VG Session or 

vishlist session or both). 

c. 2 or 3 lists need to be made up for easier management by L&T 

and DEC. (ie. one each for Languages, Tools, and Methods). 

d. Keep it simple until ve knov vhat vorks. 

e. Go vith the folloving vishlist "flow": 

SPRING SYMPOSIUM : 

Working Groups submit vishlist items received 
since last vishlist deadline and from the 
current symposium 

L&T Meetings receive vishlist items 

Vishlist items received from L&T folders 

Vishlist items received from campground 

Vishlist coordinator, Working group chairs sectionalize 

vishlist items 

AFTER SYMPOSIUM: 

Vishlist coordinator creates master lists, 
sections them off according to Working Groups 
Copy to Nevsletter Coordinator (Al) by June 15 also 
copy to Working Group Chairs and DEC 

AUGUST SIG NEVSLETTER: Vishlist Ballot in Nevsletter 

END OF SEPTEMBER/FIRST VEEK OCTOBER: Results to DEC 

FALL SYMPOSIUM: 

DEC response at symposium 

Start of next vishlist cycle vith similar time frame 
to above. 

f. Also need to provide mechanism for notifying 3rd party vendors 
of the user's vishes for items entered that are 
not DEC products. 


19. Seminars: (Joe Pollizzi) 

Barry had many more PSS suggestions that reached him at Anaheim, but 
they vere too late for Cincinnati. As a result, Barry is asking that any 
suggestions be sent to him nov BEFORE Cincinnati for inclusion in Anaheim. 

L&T has had a good grovth in the number of PSS's - from 2 to 7 even 
though there is no longer any financial benefit back to the SIG. Good 
reflection on L&T. 

The idea of compensating PSS speakers vas raised. Current feeling 
indicates that there exists many excellent speakers vho vould be more 

villing to spend the time and effort putting together a quality seminar 
if some form of compensation/recognition vere given. Even "just" free 
registration into the symposia for the veek vould be appreciated by 
many. 

Some ideas raised concerning PSS's: 

a. Possibility of 1/2 day seminars? 

b. Double teaming - vill PSS committee support tvo presenters? 

c. Selling PSS notes/text outside of seminar as a mechanism of 
revenue, and the 

d. Concept of taping the seminars. 

20. Cincinnati Clinic: (Joe Mulvey) 

Sam Vhidden asked vhether or not the CM Working Group really needs to 
have a separate Clinic from the L&T Clinic. The separate clinic vas 
justified on the basis that discussions of CM vithin DECUS are fairly 
nev and have generated much discussion during the last three symposia. 
Also, it may not be obvious to those interested that CM may/vill be 
covered by the L&T Clinic. There vere no objections to having this 
separate. L&T may vant to consider expanding the abstract for the L&T 
clinic to mention more of the products/topics that are covered. 

All products are going to be covered during the FULL clinic schedule. 
Past symposia indicate this is the best vay to handle the clinic. 

It vas decided that for the Cincinnati Symposium, Campground hosts and 
product "experts" vill vear sashes (much like Miss America!) to identify 
themselves to people coming into the clinic looking for help. 

Ve should also see if round tables can be placed in the campground 
vith the "experts" spread across the tables - this encourages group 
discussion/interaction. Rather than have the L&T doctor ansver one 
question and then have the next person come forvard, several people can 
hear/possibly provide the ansver AND reduce some of the duplicate 
questions. 
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The L&T -ANSI standard reps WILL be at the clinic and identifiable. 

Question was raised and answered : Any expert, not just DIGITAL 
employees can be a "L&T Doctor" and will be identified as such. 

L&T Masters (and any Masters from other SIGs who would like to 
participate) are expected to be available and identified. 

21. L&T Session Indexes: (Mark Kidwell) 

Several different indexes were passed out for review. The sessions 
for L&T were sorted three ways: by number, by day and time, and by 
room. All were judged to be VERY useful. A request was voiced that 
having a session list by topic or keyword would be nice. Earl Cory 
noted that this has been done. One such index was created for EVERY 
word occurrence, which created a listing book 5 inches thick!! The cost 
versus benefit for providing such extensive indexing to members is 
highly questionable. Right now, best known method is to rely on the 
working groups for providing "streams" for such comprehensive 
breakdowns. 

22. L&T Standards Activities calendar & budget: (Bruce Mebust) 

It was discussed that the Standards Coordinator must report four 
times a year on standards meetings attended by L&T reps, and on reports 
that they have provided for DECUS. 

We are looking for a FORTRAN representative. 

Jay Viley raised the question of involvement in IEEE standards 
efforts. Steve Jackson will investigate. 

Trip Reports will be forthcoming for any meetings supported by L&T. 
Reports will be given at Woods meetings, symposia, and published in 
newsletters. 

A session on standards will be given at symposia. Placeholders 
should be put in each symposium to cover active standards issues. 

23. SIG Job Descriptions: (Mark Kidwell) 

We need to have detailed job descriptions for the different positions 
in the SIG. This is needed not only for transitions within the SIG (new 
people coming in, old leaving) and "transfers", but for the SIG Council 
to document the activity of the SIG, and possibly provide justification 
for budget requests (ie. amounts needed for Woods meetings). Joe should 
be responsible for an overall description for the Working Group chairs. 

24. Alternate methods of session identification: (George Scott) 

This topic was deferred. 


25. L&T Logo: (Sam Whidden) 

It was felt that a new SIG logo would be nice, but no one had any 
ideas. 

26. Planned FY89 SIG budget (George Scott): 

Sam passed out copies of the FY89 SIG budget. 

27. Woods Meetings: (Lisa Kerby-Rodgers) 

Next Woods meeting is in Nashua on Sunday, July 24 (L&T) and Monday 
July 25 (for meeting with DEC). Need to have DECUS office start planning 
now. We would like an Inn not the Tara. Part of the reason is expense. 
If Sam had known how cheap the Houston Woods Meeting Hotel was we would 
have had a three day meeting! BUDGET & FINANCE has cut the Woods budget 
somewhat. This may not hurt us too much as not everyone shows up who is 
invited. We may want to invite several extra Working Group Chairs to 
cover for those who don't show up and increase the communication within 
the SIG. 

Celeste requested an agenda of items for Monday when at Spitbrook. 
Originally Sam wanted to allow the agenda to develop between now and 
July, but Celeste pointed out that we plan our meetings during the 
"prime vacation" time PLUS for the counterparts we often impact on the 
weekend. Celeste would therefore like to know who to request for the 
meeting well in advance. Suggestions for topics were: 

a. WG roles from the DEC developer side - How can they help DEC 

from a technical counterpart role? 

b. DEC'S view of the SIG: how have we done, how are we doing, 

and what do we need for better communication between 
DEC and DECUS L&T? 

c. Have Celeste choose which VG Chairs are going to attend. 

d. DEC company organization - how it all fits together 

e. Have several developers who have been to DECUS symposia (both 

one who's only gone to 1 and one who's an "old-timer). Give 
their view of L&T. 

f. Have both individual and group discussions - alternate 

suggestion: Have us break into several groups based on 
languages, tools, and methodologies and talk to the 
respective developers. 

g. If we get non-disclosure back, have time for the non-disclosure 

items. 

h. DEC'S approach to support of the OEM market. 

i. Have someone present to us what DEC has in mind for CASE - how 

will it affect us via changing Engineering? (Possible 
problem with Non-Disclosure) 
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j. Celeste - Would ve be interested in a presentation on 
object oriented design? Answer: Yes. 

Also would like L&T to have 3 people state how we view DEC 
(ie. participation, feedback, supportiveness). By having 
3 people present we reduce the risk of the "discussion 
becoming a many to 1 confrontation." 

Celeste - Will tentatively plan on the morning as one group, object 
oriented presentation (possibly in afternoon) ,other areas 
to be identified when who (DEC) can 

attend becomes known. Will plan on having breakout sessions 
(Languages/Tools/Integration/PDP-11) during the afternoon. 

28. SIG Activity Plan: (George Scott) 

The primary topic was travel to symposia of other chapters (Non-US 
DECUS's). For example, DECUS Australia would like an US DECUS L&T 
member to give a presentation on CASE. DECUS US L&T might pay the way. 
Anybody that wants to go outside the US should present a plan to Sam 
Vhidden. He will note the request. L&T SIG members present had no 
knowledge of a DECUS organizational body above the chapter level. 

29. Counterpart Activities: (Steve Jackson) 

Our DEC counterparts gave a report on the meeting of DEC counterparts. 
Very positive feedback came from the meeting. The use of the exhibit 
hall was talked about with a consensus that a combined schedule for the 
DEC personnel needs to be publicized/posted. The combined schedule 
consisting of a listing when a given developer is going to be at a 
campground or the exhibit hall. This is to encourage better utilization 
of the exhibit hall, DEC/customer feedback, and to move some of the 
demonstration of Digital Products BACK INTO the exhibit hall. 

30. Other Hatters: (Sam Vhidden) 

The symposium committee could publish an order form for session tapes 
with short titles to make it easier to order tapes. 

Earl noted that if your abstract has been edited (by DECUS) to 
be longer than 20 lines it won't resubmit. If trying to resubmit an 
abstract for another symposium then cut down the abstract so it will 
work and send a message to Earl to reformat it. 


Steering committee members find that DCS is extremely slow on the 
800 line even when there are only 1 or 2 users. 

Joe mentioned that there are companies that won't send representatives 
to DECUS if they can't promote the company. How can those companies be 
shown how much they're missing by staying away? Sam replied by 
mentioning the Board of Director's efforts to involve CEO's in DECUS 
management days. More articles on DECUS benefits should be appearing in 
management publications. An idea brought up was that a video for CEOs 
and MIS managers on the symposia should be done showing the benefits of 
attendance. DECUS Leadership could then request free copies of the 
video to show their management (have the video as part of a LUG'S 
library also?). Perhaps this way, some steering committee members won't 
have to take vacation to attend symposia, woods meetings. 
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VAX LANGUAGES AND TOOLS RELEASE STATUS 


VAX (tm) Ada (r) - Q*056 

Current Version: VI.5 

VI.5 Began Shipping: February, 1988 

Major Features : - Full ANSI Language 

- Production quality 

- Highly integrated into VAX/VMS Environment 

- Multi-language capabilities 

- Comprehensive diagnostics 

- U.S. Government validated 

- Full symbolic debugging support 

- VAX Language-Sensitive Editor support 

(tm) VAX is a trademark of Digital Equipment Corporation 
(r) Ada is a registered trademark of the U.S. Government (Ada Joint 
Program Office) 


VAXELN Ada - Q*A97 

Current Version: VI.2 

VI.2 Began Shipping: March, 1988 

Major Features: - Compatible with VAX Ada 

- Retargetable to real-time/embedded environment 

- Remote debugger 

- Tailorable run-time environment 

- Run-time library retargetted from VAX/VMS to VAXELN 

- Package of interfaces to VAXELN services 

VAX APL - Q*020 

Current Version: V3.0 

V3.0 Began Shipping: July, 1987 

Major Features: - Nested arrays 

- Several minor Apl extensions 

- Performance improvements 

- APL can call other VAX languages which adhere 

to the VMS calling standard 

- Multi-key ISAM 

- Full screen editing 

VAX BASIC - Q*095 

Current Version: V3.2 

V3.2 Began Shipping: November, 1987 

Major Features: - Embedded graphics statements 

- Structured error handling 

- Optional line numbers 

- Print using format strings 
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VAX Bliss - 0*106 

Current Version: V4.4 

V4.4 Began Shipping: February, 1988 

Major Features: - Ease of use 

- /Check qualifiers 

- /Cross reference switch 

- VAX Language-Sensitive Editor support 


VAX C - Q*015 

Current Version: V2.4 

V2.4 Began Shipping: May, 1988 

Major Features: - ANSI X3J11 features 

- Full debug support 

- CDD support 

- VAX Language-Sensitive Editor support 

- VAX Source Code Analyzer support 

- Improved run-time routines for UN*X compatibility 

- Shareable run-time library is distributed as 
part of VMS 

(VAX C/ULTRIX - ships with ULTRIX-32 kit, currently shipping V2.4, October 1987) 

VAX COBOL - Q*099 

Current Version: V4.0 

V4.0 Began Shipping: January, 1988 

Major Features: - ANSI-85 implementation 

- Multi Stream DBMS Support 

- DSLA Support 

- Federally Validated at a High Level, ANSI 85 

- VAX Language-Sensitive Editor support 

- Screen handling extensions 

- Extended DML 

- Support for VAX COBOL Generator 


VAX COBOL Generator: Q*365 

Current Version: VI.2 

VI.2 Began Shipping: January, 1988 

Major Features: - 4GL approach to COBOL programming 

- Graphical interface 

- Generates error-free VAX COBOL code 

- direct access to RMS and Rdb 

- promotes structured design 


VAX DEC/CMS - Q*007 

Current version: V3.0 

V3.0 Will Begin Shipping: May, 1988 

Major Features: - A callable interface 

- New security features 

- Significantly improved performance 

- Groups for the easy organization of related files 

- VAX Source Code Analyzer support 

- Binary and ASCII file support 

- Distributed support thru DFS 
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VAX DEC/MMS - Q*500 

Current version: V2.3 

V2.3 Will Begin Shipping: May, 1988 

Major features: - Support for VAX Source Code Analyzer 

- Support for CDD 

- Support for TDMS 

- Support for FMS 

- Support for CMS V3.0 


VAX DEC/Shell - Q*143 

Current Version: V2.0 

V2.0 Began Shipping: January, 1987 

Major features: - An alternate command line interpreter 
— UUCP, NROFF and termcap support 

- A set of commonly used UN*X utilities 

- Bourne Shell 


VAX DEC/Test Manager - Q*927 

Current Version: V2.3 

V2.3 Will Begin Shipping: May, 1988 

Major features: - Ability to test interactive applications on a 
character cell terminal 

- Increased integration with VAX DEC/CMS (can store 

tests in a CMS library for Test Manager retrieval) 

- Performance Improvements 

- Ability to edit session files 


VAX DOCUMENT - Q*ZE7 

Current Version: VI.0 

VI.0 Began Shipping: September, 1987 

Major Features: - Generic markup language 

- Multiple document designs and styles 

— Sophisticated page composition and pagination 
software 

- Complete book-building facilities 

- High quality output 

- Integrated into the VAX/VMS Environment 

- VAX Language-Sensitive Editor support 


VAX FORTRAN - Q*100 

Current Version: V4.8 

V4.8 Began Shipping: March, 1988 

Major Features: 

• VAX Language-Sensitive Editor support 

- Global optimizations 

- CDD support 

- Records 

- VAX Source Code Analyzer support 

(VAX Fortran on ULTRIX - Q*A99, Currently shipping V4.7 December, 1987 
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VAX Language-Sensitive Editor: Q*057 
Current Version: V2.2 
V2.2 Began Shipping: May, 1988 
Major Features: - Interfaces with CMS, SCA 

- User diagnostic file support 

- Supports Ada(r), Basic, Bliss, C, COBOL, Fortran, 

Pascal, PL/I, SCAN, EPascal, Dibol, and 
others 

- Edit, compile, review, and correct compilation 

errors within a single editing session 

- Speeds up source code entry using formatted 

language-specific source code templates 

- Provides for interactive editing capabilities during 

a debugging (VAX Debug) or performance analysis 
session (VAX Performance and Coverage Analyzer) 

- User tailorable and user extensible 

- Extensive on-line help for supported VAX languages 


VAX NOTES: Q*960 - Server 
Q*ZIT - Client 
AL960A9-PD (see note) 

Current Version: VI.3 

VI.3 Began Shipping: January, 1988 

Only functional change is to support LMF. Therefore, this version is 
for VMS V5.0 only. 

Major Features: Computer-based conferencing software 

- Supports on-line discussions between groups of people 

- Project team communication 

- Maintains a permanent record of discussions 

- Easily accessible by variety of search criteria 

- Unique distributed architecture 

- Server based 

- Leadership performance in DECnet networks 

- Easy discussion between geographically 

dispersed groups 

- Easy to learn and use 

- Choice of DEC standard editing styles 

Note: The 4-user license contains server capabilities that allows 

four simultaneous users of nodes. The UBC options is additive (i.e., 

4-user, 8-user, 12-user). 

VAX Pascal - 0*126 

Current Version: V3.7 

V3.7 Began Shipping: April, 1988 

Major Features: - New ANSI standard 

- Performance/runtime optimizations 

- CDD support 

• VAX Language-Sensitive Editor support 

- Compatibility support for VAXELN Pascal 

- Source line debugging 

- VAX Source Code Analyzer support 
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VAX Performance and Coverage Analyzer - Q*119 
Current Version: V2.0 
V2.0 Began Shipping: April, 1988 

Major features: - Helps to find execution bottlenecks in application 
programs 

- Provides test coverage analysis to determine which 

lines of an application are executed by a given 
set of test programs 

- Has an interface to the VAX DEC/Test Manager 

- Windowing 

- Ada Support 

- DSLA 


VAX PL/I - 0*114 

Current Version: V3.1 
V3.1 Began Shipping: December, 1987 
Major Features: -VMS integration 
-IBM features 

-VAX Language-Sensitive Editor support 
-CDD support 

-Compile-time pre-processor 


VAX Software Project Manager - Q*A82 
Current Version: VI.1 
VI.1 Began Shipping: January, 1988 

Major features: - A software development project management system 

designed to plan, schedule, and estimate projects. 

- Contains WBS (Work Breakdown Structures) that 
shows all tasks in a tree structure. 

- Choice of user interface, menu-driven or command 
line mode 

- Uses traditional project management tools, PERT 
and CPM (Critical Path Method), and Gantt charts 
to help keep projects on time 

- Easy to use graphic interface 

- Generates a variety of reports and charts 

- Enhanced date and time 

VAX RPG II - 0*631 

Current Version: V2.1 

V2.1 Began Shipping: September, 1986 

Major Features: -Conforms and is an extended implementation of the 
IBM RPGII defacto standard 
-Fast compile and runtime performance 
-Full screen editor 

-Compatible with IBM implementations on 
Systems 3, 34, and 38 
-CDD support 

-FMS translator for System 34 screen handling 


VAX Source Code Analyzer - Q*ZBZ 
Current Version: VI.2 
VI.2 Will Begin Shipping: May, 1988 
Major Features: - Faster LOAD and query performance 

- Multi-language source code cross-reference, 
navigation, static analysis tool. More than 
just a browser. 

- Works for entire system not just individual 
modules. 

- Closely integrated with LSE. All SCA 
commands are available from within the editor 
and user can directly access and modify the 
appropriate source code even if using CMS. 

- DSLA 

VAX Scan - Q*495 

Current Version: VI.1 

VI.1 Began Shipping: January, 1987 

Major features: - A complete VAX programming language used to create 
programs that deal with pattern matching and 
text transformation 

- Used for creating translators, preprocessors, 

filters, and parsers 

- To build tools for converting data from other 

vendor's computing equipment 

- Finds and replaces text in files 


VAXset - Q*965 

Q*966 (Educational License) 

Current Version: V6.0 

V6.0 Will Begin Shipping: May, 1988 

A package of software engineering tools consisting of: 

- VAX DEC/CMS 

- VAX DEC/MMS 

- VAX Language-Sensitive Editor 

- VAX Performance and Coverage Analyzer 

- VAX DEC/Test Manager 

- VAX Source Code Analyzer 


VNXset - Q*A80 

A*A81 (Educational License) 

Current Version: V5.0 

V5.0 Will Begin Shipping: May, 1988 

A package of software engineering tools consisting of: 

- VAX DEC/CMS 

- VAX DEC/MMS 

- VAX DEC/Shell 

- VAX C 


L&T-45 


L&T-46 



Software Portfolio 

Base Program Development Portfolio 
Q42DA 
QB2DA 
Q22DA 
Q02DA 
Q32DA 

Current Version: VI.0 

VI.0 Began Shipping: January, 1987 

A package of licenses that can be rented or a monthly basis 
for VAXstations or MicroVAXs. Includes licenses for: 

- VAX ACMS 

- VAX APL 

- BASEVIEW 

- VAX BASIC 

- VAX BLISS 

- VAX C 

- VAX CDD 

- VAX COBOL 

- VAX DATATRIEVE 

- VAX DBMS 

- VAX DEC/CMS 

- VAX DEC/MMS 

- VAX DEC/Test Manager 

- VAX FMS 

- VAX FORTRAN 

Extended Program Development Portfolio 
Q42DB 
Q82DB 
Q22DB 
Q02DB 
Q32DB 

Current Version: Vl.0 
Vl.0 Began Shipping: January, 1987 

This package includes all licenses that are in the Base 
Program Portfolio plus: 

- VAX Ada - VAX RALLY 

- VAX COBOL Generator - VAXELN Ada 

- VAX LISP - VIDA 

- 0PS5 


- VAX GKS 

- VAX LSE 

- VAX Notes 

- VAX PASCAL 

- VAX PCA 

- VAX PL/I 

- VAX Rdb/VMS 

- VAX RPG II 

- Remote System Manager Server VMS 

- Remote System Manager Client VMS 

- VAX SCAN 

- VAX SCA 

- VAX TEAMDATA 

- VAX TDMS 

- VAXELN Toolkit 


Program Development Run-time Portfolio 
QZZDC 
Q32DC 
Q02DC 

Current Version: Vl. 0 

Vl.O Began Shipping: January, 1987 

This package is used for application run-time environments on 
MicroVAX systems only. The products included are: 


VAX ACMS Remote Access Option 
VAX ACMS Run-time Option 
VAX CDD 
VAX DATATRIEVE 
VAX DBMS Run-time Option 
VAX FMS 
VAX GKS 


VAX LISP 
VAX Notes 
VAX OPS5 

VAX Rdb/VMS Run-time Option 
VAX TDMS Run-time 
VAX TEAMDATA 
VIDA 
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Languages & Tools SIG 
WISHLIST QUESTIONNAIRE 

Name:_ Title_ 

Company:_ 

Address:_ 


_Phone: ( ) _ 

Network Address:_Date:_ 

At Symposium, return this form to the L&T Campground host or submit it at the L&T Wishlist 
Session. Or mail it to: Bob van Keuren, L&T Wishlist Coordinator, User Ware International Inc., 2235 
Meyers Ave, Escondido, CA 92025; (619)745-6006 

The Languages & Tools SIG is principally concerned with the DEC and public domain software products listed 
below. If your request directly involves one of these products, please check which one (if you have more than one 
request, please use a separate form for each): 



Debug 


Bliss 


CMS 


TPU 


C 



Pascal 


Basic 


MMS 


EVE 


Ada 1 



Fortran 


Cobol 


LSE 


EDT 


APL 


: 

Document 


Dibol 


SCA 


TECO 


RPG 



VAX Notes 


Emacs 


PCA 


PL/I 


Scan 



Test Manager 
Runoff & DSR 

TfcX & m E x 

Cobol Generator 
Software Project Mgr 


If your request or suggestion doesn’t relate to one of the products listed above, check which one of the following 
Language & Tools SIG topics it concerns: 


Pre-Symposium Seminars 
Session Notes 
DECUS Store Item 

Other L&T SIG topic: 


Z] 

Newsletter 

|—i 

Symposium Sessions 

— 1 


Masters Program 
Information Folder 

— 

Working Group Activities 
SIG Tape 



Wish List Request —brief description: 


Complete description—please explain your request thoroughly; don’t assume we know details of other products or 
services; give examples. _ 


*Ada is a trademark of the DoD 
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GLOBAL 
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SPAT A 


Volume 1, No. 6 May. 1988 

HUMPS leans you never have to say you're sorting. 


$ V I E W (Editor) 

I don't want this piece to sound like an obituary, but I'm 
afraid that at least a little of that aspect is inevitable, so 
here goes: on February 24, Bill Leroy resigned from DECUS. At 
that point, his numerous DECUS hats included chairmanship of both 
the Atlanta LUG and the SIG Publications Committee (which brings 
you this amazing compendium of editorial excellence every month). 
Bill had done some reflecting, and come to the (unfortunate for 
DECUS) conclusion that his heavy DECUS commitment was just not 
compatible with the rest of his responsibilities. 

I first met Bill bright and early on the Sunday morning 
which preceded the initial Symposium I attended after joining the 
MUMPS Steering Committee. We chanced to sit next to each other 
in a leadership training session, and proceeded to work together 
on the assigned problems. This pure coincidence turned out to be 
a great stroke of luck. Back then, Bill was the RT-11 SIG News¬ 
letter Editor, and already totally qualified in DECUS leadership 
arcana. I was brand new, and feeling like I had just parachuted 
into a strange city with a blank page where the roadmap was sup¬ 
posed to be. Bill did a lot to put information on my roadmap. 
For that, and for all the other ways Bill helped me personally, 
and DECUS in general, I would like to express my thanks. And, I 
am sure you will all join me in wishing Bill the best of luck in 
all his future endeavors. 


Just look at all the goodies we've cooked up for you in 
Cincinnati: 


General Interest 


MUMPS Roadmap 

M010 

Mo 

9:00AM 

Multi-Lingual Translation of Text 

M021 

Mo 

9:30AM 

DECUS Abstract Keyword Index 

MO 14 

Mo 

10:30AM 

Large MUMPS Systems 

MO 0 5 

We 

4:00PM 

MUMPS System Management Panel 

MO 06 

We 

5:00PM 

MUMPS Tricks and Treats 

M 0 0 8 

Th 

8:00PM 

MUMPS Development Committee Report 

MO 19 

Fr 

10:00AM 

MUMPS Future Planning Session 

MO 18 

Fr 

1:00PM 

Tutorials 




Multi-Way B-Tree Database Implementation 

M009 

Mo 

11:30AM 

Software Prototyping 

M020 

Mo 

6:00PM 

MUMPS Tutorial, an Overview 

MO 16 

Mo 

7:00PM 

Public Domain Software 




The Government and MUMPS 

M004 

Tu 

2:00PM 

Medical Query Language (MQL): An Application 




Generator for MUMPS Applications 

MO 17 

We 

3:00PM 

Full Relational Database in the Public Domain 

M022 

Fr 

9:00AM 

DSM Specific 




DSM Product Panel 

MO 15 

Tu 

9:00AM 

DASL--A 4th Generation Application Generator 

MO 11 

Tu 

10:00AM 

DECRAD: Radiology Application System 

MO 12 

Tu 

1:00PM 

DSM and Networking 

M007 

We 

12:00M 

FMS, All-IN-1, and MUMPS 

MO 13 

We 

2:00PM 

MUMPS Dump Busters 

M002 

Th 

7:00PM 


SHQROLOG 

May 8 
May 16-20 
June 13-17 
October 17-21 


Submission deadline for July newsletter 
Spring '88 Symposium; Cincinnati, OH 
MUG '88 Conference; New Orleans 
Fall *88 Symposium; Anaheim, CA 


MMP-1 


MMP-2 



BORDER("Podium") 


EVERYBODY misuses the word podium. The podium is the wooden 
contraption you stand behind, clamp your microphones to, and rest 
your note cards on while you’re making a speech, right? (Joe 
Clubmember told several amusing stories while he was behind the 
podium....) Wrong! The podium is the dais or platform Joe was 
standing on at the time. The word comes from the Greek root pod- 
vhich means foot . The same root appears in the English word for 
"foot doctor," podiatrist. And, to finish straightening things 
out, the proper term for the microphone and note card stand Is 
lectern, from the Latin word lector, meaning reader. 


$NE XT 

Did you know that there is a Kermit written in HUMPS? Find 
out about that, and what really went on at the Cincinnati Sym¬ 
posium, in the July issue. 

$NE XT(SDRDER)="Mission" 


^RANDOM 

"Unless you're the lead dog, the scenery never changes." 
--Bumper sticker 
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From. the Chair 
Charles W. Hussain 
RSTS SIG Chairman 


A new generation of RSTS managers are meeting the 
challenges of their new jobs without benefit of the rich RSTS 
culture we "old timers” enjoyed. Gone are the RSTS 
Professional magazine and the CACHE SUFFER newsletter which was 
once sent to every DECUS member expressing an interest in RSTS. 
Both publications were filled with how-to articles, technical 
tips, letter columns. new utilities, and discussions about 
what's new in RSTS. 

Our SIG Editor, Terry Kennedy, is bringing to the RSTS 
pages of this newsletter all those "cultural" benefits for the 
RSTS community. There is, however, a small problem (pun 
intended) . Only a very small part of the RSTS community in 
DECUS receive the SIGs NEWSLETTERS. This is no doubt in some 
part due to our SIG's past record of not publishing regularly. 
We believe that Terry has resolved this problem. 

We now need your help in spreading the word to the RSTS 
community. When you speak to other RSTS users, at LUG 
meetings, at Symposia, or to consulting clients, wherever, 
please make them aware of the revitalized newsletter. Carry the 
message that it is available to them as a source of information 
and as a place for sharing problems, solutions, neat bits of 
code, and general RSTS hints and kinks. 

We know from surveys that there is a large RSTS community. 
We know that this includes many people new to RSTS using 
versions ranging from 5c to 9.5. "With your help in spreading 
the word, your help in contributing articles and sharing 
insights, this newsletter can provide a meaningful service to 
all of us who use RSTS, DEC’S friendliest, operating system. 

NEXT MONTH: Why upgrade to the latest version of RSTS? 


we'll be bringing you coverage of the high points in the RSTS 
Newsletter. 

This month, we have a condensed abstract of the combined 
Spring/Fail 19S7 RSTS SIG Tape Copy tape. This tape contains 
submissions from users like yourself. If you have some handy 
programs or information related to RSTS, feel free to submit it 
to our Tape Copy Coordinator, Franklin Mitchell (See the 
article itself for more details) . The entire tape is on-line 
on the RSTS Newsletter system at (201) 915-9361. 

We also have Digital's responses to the Fall 1987 RSTS 
wishlist items in this issue. Special thanks to Ginger Landry, 
RSTS/E Product Manager, and the entire RSTS development team 
tor their time m preparing these responses and agreeing to 
share them with us. 


Since the how- to term has been removed, here is how to 
contact me for submissions, etc.: 


Via US Mail: 


Via UPS, FedEx, etc.: 


Terence M. Kennedy 
St. Peter's College 
Department of Comp. Science 
2641 Kennedy Blvd. 

Jersey City, N.J. 07306 
(201) 435-1890 


Terence M. Kennedy 
St. Peter's College 
Department of Comp. Science 
121 Glenwood Avenue 
Jersey City, N.J. 07306 
(201) 435-1890 


You may electronically submit material by calling the RSTS 
SIG bulletin board system at (201) 915-9361, or you may reach 
me as user KENNEDY on both DCS and DECUServe, if you have 
access to either of those systems. 


You may submit material on RX50 ' s or RX33 ' s (in RSTS or 
FT 11 format), on 300, 1600^3200, or 6250 BPI 9-track tape (in 
DOS, ANSI, BRU, RSTS BACKUP or VMS BACKUP format), or on- PC-DOS 
lioppies (5!4 or 3H inch format) . If you are really desperate, 
I can also accept RSTS or RT11 format RL02 and RK07 disks. You 
may also submit hardcopy documents, but these will take longer 
to get into print. 


From the Editor 
Terry Kennedy 

It's Spring again (or will be by the time you read this), 
ar.d that means it's time for another Symposium - this time in 
Cincinnati. As usual, the SIG has a full set of sessions 
scheduled. As I've mentioned before, a Symposium is an event 
not to be missed - if you can get your company to send you, 
great - if not, you might seriously consider taking the time as 
vacation and going anyway. However, if you can't make it. 


Cincinnati 


less ion 

Day 

Time 

RSC16 

Mon 

9:00 AM 

RSQ02 

Mon 

9:30 AM 

RSQ03 

Men 

12:00 PM 

RS028 

Mon 

12:30 FM 

RS00 5 

Mon 

1:30 PM 


Symposium Session List 
Title 

RSTS Roadmap 
RSTS Announcements 
RSTS V9.6 Tech Changes 
EMT calls from BP2 
What is RSTS/E LAT? 
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R S I 2 2 

Mon 


0 0 

PM 

RSTS/VMS Compatibility Manual 

R S 0 0 6 

Mon 

3 

30 

PM 

PBS Overview 

RSC 04 

Mon 

8 

00 

PM 

Intro to RSTS Optimization 

ES019 

Men 

9 

00 

PM 

RSTS Performance Cunino 

RS129 

Tue 

11 

00 

AM 

RSTS V8 Q&A 

RS010 

Tue 

12 

0 0 

PM 

Resident Libraries 

RSC2 5 

Tue 

2 

30 

PM 

RSTS Tech Tips I 

R SOU 

Tue 

3 

30 

PM 

VMS System Mgt. for RSTS Sys. Mgrs 

r £C 12 

Tue 

5 

00 

PM 

File transfer RSTS to VMS 

RS020 

Wed 

9 

00 

AM 

RSTS Internals Update 

RS017 

Wed 

10 

00 

AM 

RSTS SIG tape / library 

RS001 

Wed 

10 

30 

AM 

RSTS System Modifications 

R S C15 

Thu 

9 

00 

AM 

DECnet/E Froarair.rr.ing 

RS007 

Thu 

10 

00 

AM 

Terminal Services 

RSC09 

Thu 

11 

00 

AM 

RSTS RMS-11 

RSC30 

Thu 

12; 

00 

PM 

Security for RSTS/E systems 

RS026 

Thu 

1: 

00 

PM 

RSTS Tech Tips II 

RS013 

Thu 

3 

00 

PM 

RSTS/VMS BASIC Conversion 

RS014 

Thu 

5: 

00 

PM 

RSTS/VMS Q&A 

RSC18 

Thu 

9 

00 

PM 

Asynch I/O from 3P2 

RSC21 

Thu 

10 

00 

PM 

RSTS/E Interprocessor Link 

RS003 

Fri 

11 

00 

AM 

BACKUP for System. Managers 

RSC23 

Fri 

12 

00 

PM 

RSTS Wish List 

R S 02 7 

Fri 

1 

30 

PM 

RSTS SIG Wrap-up 

delated 

Sessions 

. o; 

f Intere 

st: 

Session 

Day 


Time 

Title 

LTG 31 

Mon 

11 

: 15 

AM 

PDP-11 Language Status/Futures 

RXC04 

Mon 

4 

: 30 

PM 

PDP-11 Futures - User’s View 

RX003 

Mon 

6 

: 00 

PM 

MSD Meets DECUS [Ed. Note: MSD is 


the organization within Digital re¬ 
sponsible for the current PDP-11 
product line.] 


1987 RSTS SIG Taps Copy new Available 

****** 1937 Nashville/Anaheim RSTS SIG Tape. * * * * * * 

Please share your RSTS "goodies” with the RSTS SIG. Please 
send your 1988 RSTS SIG Tape submissions to 

Franklin Mitchell (DCS MITCHELLF) 

RSTS SIG Tape Copy 
Erskine College 
1 Washington Street 
Due West, SC 29639-0086 
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Fall 1987 RSTS Wish List Responses 

[Ed. note - this is a transcription of the supplied wishlist 
forms, combined with Digital's written responses. I apologize 
for any typographical errors which may creep in... Also, I 
have added some information (in brackets) where I thought it 
might prove useful.] 
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Wl) DECnet/E - Add a YMS-compatibie proxy login to DECnet/E. 

Reason: Many RSTS/DECnet sites are managed by a common 
staff (multiple systems, 1 manager). The day-to-day 
copying of files currently requires the account and 
password to be supplied each time. This is a lot of typing 
and is also a security opening. 

A1) This is an excellent idea. We are currently investigating 
many different options in this area. Technically, this is 
a difficult problem (Tech. 3). While the actual 
implementation may be relatively small, a lot of effort 
must be expended researching and resolving the myriad 
security issues that a proxy login feature implies. 
Providing this feature would be very valuable to RSTS/E 
and DECnet/E, for exactly the reasons that were already 
stated with submission cf this wish (Prod. 1). 

W2) DECnet/E - Add support for the KFT /BL qualifier to the 
DCL copy command, or better still, to have DCL append it 
automatically. 

Reason: Many files require the /3L switch to successfully 
transfer across the net. DCL does not generate or support 
this switch. Therefore, users must know both the DCL and 
KFT commands. 

A2) We are looking at ways with the architecture committee to 
remove the need for /BL entirely. (Tech. 1, Prod. 2) 

W5) Asynch DECnet! 

Reason: Good idea! 

A3) We hope to be able to commit to provide this feature in 
some future release of DECnet/E. (Tech. 3, Prod. 1) 

W4A) RMS-11 - Asynchronous I/O capability for RMS, especially 
with the "get next key" directive. 

Reason: Would improve performance of typical RMS 
processing for report generation or similar applications. 

W43) RMS-11 - Asynch I/O as in RSX 

A4) This capability would require more than minimal effort. 
Hence we do not expect it will happen in the near future. 
(Tech. 2, Prod. 2) 

W5) Executive - Add supervisor mode library support, as in M & 
M-plus. For user built libraries + system libraries such 
as RMS. 

A5) This is a good idea and has been requested in the past. We 
are investigating this feature. (Tech. 2, Prod. 2) 


V5; Executive - Mere than 65536 disk clusters. 

Reason: Less waste. 

AS) This is also a good idea, however it would require a major 
re-write of FI? therefore it is very low on our priority 
list. (Tech. 3, Prod. 3) 

W7) Executive - Allow a default disk to be defined for each 
account. 

Reason: Continually specifying a disk name is tedious and 
prone to error; using multiple disks for the public 
structure significantly degrades performance. 

A?) Although this is a good idea, it is technically hard to 
implement. (Tech. 3, Proa. 2) 

WS) Executive - Ability to specify a KB using the new 
interface style designation like KBG12: in all those 
SYS() calls that ask for an integer KB number. At least 
give us a simple SYSU call that would take the string 
"KBG12:" and return the integer KB number. 

Reason: I bought a new terminal interface and had to 
modify and recompile seven million programs. 

A8 ) Done in FSS - SYS(CHR$<6%)+CHRS(-10%) + . . . > (Tech. 0, 
Prod. 0) 

W9) Executive - In FSS, allow the character to complete a 

name or type field for wildcard lookup. The exec could 
simply convert the ' x ' to multiple ' ?'s. Leading *’s 
could be disallowed for ease of implementation. 

Reason: DIR A*.BAS is easier than DIR A?????.BAS 

A9) We will take this into consideration in the future. 
(Tech. 1, Prod. 1) 

W10) Executive - Would like a system service to get/put DCL 
symbol definitions like VMS LIB$GETSYMBOL and 
LIBSPUTSYMBOL. Also, LIBS DOCOMMAND (hope, hope!) 

Reason: Many user applications are being done in DCL and 
more and more higher level languages need to interface 
with DCL. Reading and writing intermediate files to 
communicate is a hack I 

A1Q) We consider this difficult to do therefore it is 
currently a low priority item. (Tech. 3, Prod. 2) [Ed. 
note - with enough spare time, it *is* possible to figure 
out how to read symbols from a program. Writing them is 
substantially more difficult. One of the major problems 
is that since the method involved is undocumented, it 
changes from revision to revision (radically!). I had it 
figured out for 9.1, but never updated it for later 
versions.] 
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VIIExecutive - Allow large files to be accessed without 
excessive window turning. 

Reas on: Files that require several retrieval windows, 
ever, at cluster size 256, could be optimized. Suggest a 
cluster number/block count double word type of retrieval 
entry similar to CDS format. 

All) Good idea - we've had this one on our list, but with a 
method that won't change cn-disk structure. (Tech. 3, 
Prod. 1) 

hi2) Executive - Improved performance from the scheduler. 

Reason: Scheduler overhead has become a significant 
overhead on large memory, heavily loaded systems. 

A12) We are looking at ways to further optimize it. (Tech. 3, 
Prod. 2) 

W13) INIT - Allow IIIIT to format and place a RSTS file 
structure on an RX33 diskette as a 1-step operation. 

Reason: 1) This will prevent users from wiping out the 
RDxx with the diagnostics! 2) This collects all the 
preparation steps for RX33 media (which DEC supplies only 
in unformatted mode) in one convenient location. 

A13) We are investigating the possibility of enhancing the 
DSEIKT option cf INIT to allow for the formatting and 
initialization of RX33 diskettes for some future release 
cf RSTS. 

W14) DCL - Faster DCL 

Reason: It's too SLOW 

A14) This is an ongoing process. (Tech. 3, Prod. 1) 

W15) DCL - Use symbols as in VMS: 

$ DCTT=="SFOO.EXE" 

$ DOIT paraml param2 
(almost like user CCL) 

Reason: User defined CCL's / VMS compatibility 

A15) Good idea, but we couldn't make it VMS compatible and 
compatible with current DCL. (Tech. 3, Prod. 1) 

W15) DCL - Wildcard like VMS 

Reason: VMS compatibility 

A16) We are investigating this to see what can be done, if 
anything. (Tech. 3, Prod. 3) 

W17) Define values for escape, linefeed, return, etc. within 
DCL . 


Reason: We use several "bold" prompts on video terminals 
and are forever defining escape of one form, or other, 
using it once and clearing it out. 

A17 > It is better that only the people who need it, define it 
themselves rather than increase everyone's symbol table 
overhead. (Tech. 2, Prod. 3) [Ed. note - We have a program 
called 'spit' which checks the terminal attributes first, 
and then performs the necessary prompting , for example: 
SPIT BOLD,"Enter option",NORM] 

W18) DCL - Help more like VMS, where one can enter the subtopic 
at "press RETURN to continue..." 

Reason: VMS compatibility 

A13) Good idea. Not as easy as it sounds. (Tech. 2, Fred. 2) 

W19A) DCL - Here's a little one - how about being able to 
repeat the last line input (to DCL) with minimal editing? 

W19B) DCL - Allow interactive cmd. editing & retrieval of the 
last 10 (or 20) cmnds. 

W19C) DCL - Comm, and line editing in DCL. (This is more 
important to me than LAT support). 

W19D) DCL - It seems to me that it would be nice if you could 
recall the last few commands you had typed. I've seen it 
in VMS. 

A19) This is a very nice feature. It would be hard to do and 
require major work in TERSER. Also potential large 
increase in memory usage. (Tech. 3, Prod. 2) [Ed. note - 
This is available in the CLE package in the '87 SIG tape. 
Be sure to get the one that doesn't require elevated 
privileges (That's the one in the [87,5] account). 

W20) DCL - REMOVE/JOB=9/QUERY would print a SYSTAT-like line 
anc ask "Really remove?" 

Reason: I don't want to kill the wrong job. 

A20) Good idea. We will look into this sometime in the future. 
(Tech. 2, Prod. 1) 

W2I) DCL - Exit with no prompt 

Reason: Same uses as Basic-Plus's exit with no prompt. 

A21) At some point in the future, we will look into this. 
(Tech. 2, Prod. 2) 

W22) Enhance the SET command by giving the /QUERY capability to 
more of the SET commands. 


RST-8 


RST-9 




A 2 2) Good idea. We will consider this sometime in the future. 
{Tech. 2, Prod. 1) 

W23) For SHOW QUOTA, the ability to specify at least: a PPM. 
better: a wildcard PPN, best: A PPM range. 

A23) Good idea. We will commit to this in a future release. 
(Tech. 1, Prod. 2) 

W24) DCL - Mew DCL command: SET SYSTEM/NOBULL[DOG] 

A2 4) We like / Bl T LL_DOG but not / U O B T JL L _D OG ! How about 
/HO_CHESKIRE_CAT? {Tech. 1, Prod. 1) 

W2 5) DCL - Please provide document at ion/examples of more 
complicated DCL procedures - currently each function is 
detailed but very little attention is given to how to 
actually use them. 

A25) Good idea. We will consider this sometime in the future. 
[Ed. Note - RSTS Engineering usually gives a talk on 
'Advanced DCL' at Symposia. You could order the audio tape 
(see the Symposium information packet). Also, the examples 
from that presentation (and others) are on the '87 SIG 
tape in account [87,1].] 

W26) DCL - Pass substituted symbols to programs {like VMS). 

Reason: 1) VMS compatibility 2) Eliminate generation of 
temporary command files by "main" .COM files. 

A26) Highly desirable, but very hard to do. (Tech. 3, Prod. 1) 
[Ed. note - See my article "Why you can't manipulate DCL 
symbols" right after this wishlist article. ] 

W27) DCL - Don't charge the (sometimes large) DCL .TMP workfile 
to a user's disk quota. 

Reason: I'm tired of explaining several times a day to 
students why they can't log out even though DIR says they 
are below quota. 

A27) We are considering ways of resolving this issue. One 
method under consideration is placing all DCL .TMP files 
into one account, therefore the user is not charged for 
the disk space being taken up by that file. 

W23) DCL - Copy was /RETAIN 

Reason: The way it was (V8). Way did it change? 

A28) Changes was made for VMS compatibility. You are creating a 
new file, sc the default should be /NORETAIN. (Tech. 1, 
Prod. 3) 

W29) PBS - Add an /APPEND switch to a /LOG_FILE= so we can 


append batch logs together. 

Reason: Reruns of batch jobs erase the previous loq file 
and often fail because of other than the original problem. 

A29: This is a good wish and we will consider it for seme 
future release of RSTS/E. (Tech. 2, Prod. 2) 

W30) PBS - Support PBS over DECnet 

Reason: To be able to print to a device on another node. 

A3C) This has been a long-standing wish for PBS. We continue to 
keep it in the list and at some point will consider this 
when planning updates. (Tech. 3, Prod. 1) 

W 31) P 33 - Remove words like "entry" etc. from a show queue 

command and put in the form name instead. 

Reason: There is all sorts of information we need about 
the queue without having header info repeated on each 
line 1 

A 31) We have had a wish in the past for a selected SHOW 
ENTRY/3RIEF=( ) command. This would be more useful to a 
wide variety of customers. (Tech. 3, Prod. 2) 

W32; PBS - A way to initialize/set-up a printer before and/or 
after printing a job. 

A3u) We are looking at it. In the meantime, you may want to 
try: Allocate device, PIP setup-file to it, Allocate 
device to PBS. (Tech. 3, Prod. 2) 

W33} RSX emulator - Allow RSX-style binary I/O (IO.RNE...) to 
KB : 

A33) Thank you for your suggestion. We will look at it (already 
have MODE 1% in RSTS-style I/O). (Tech. 2, Prod. 3) 

W34) RSX emulator - Memory-resident overlays 
Reason: Execution speed 

A34) It's in the manuals - TKB and MAKSIL explain how to create 
code only (read-only data) memory-resident overlays. 
(Tech. 0, Prod. 0) [Ed. note - You could also build a 
normally-overlaid task and run it from the virtual disk] 

W35) Backup package - Backup to handle command lines longer 
than 1024 characters. 

Reason: So we can include/exclude a sufficient number of 
files. 

A35) We will look at a way for you to select more files. (Tech. 
1, Prod. 1) 
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W53; Backup package - Have Backup create a bootable medium, or 
m.ake SAVRES gc faster on TK50’si 

A36; Ho future development in SAVRES. Use RECOVR.COM (Tech. 3. 
Prod. 1) [Ed. note - RECOVR.COM is documented only in the 
V9.C Release Notes - it allows you to make a bootable tape 
which can then be used to restore BACKUP savesets. Also 
see the 1987 SIG tape, which has a routine to make 
combined DOS/ANSI (Bootable BACKUP) tapes.] 

W3“) Backup package - Backup should produce some stats such as 
tape errors/tape, last file written to each tape, 
elapsed time, etc. 

A3") We will look at this sometime in the future. (Tech. 2, 
Prod. 2) 

W3S) Backup package - Backup should be able to use the sate 
account wildcarding as ACTMGR: 

BACKUP DUO: [100-200,*3 *.* FOO.BCK 

A32} At seme point we will look at a way to select more files, 
maybe using ACTMGR's wildcarding. (Tech. 3, Prod. 3) 

W39) All - Don't let RSTS/E die! 

Reason: It's the best OS around! 

A 3 3) RSTS has proven itself over the years and has a large 
dedicated customer base. Thank You for your investment... 

W40) All - Keep up the good work! 

A40) Keeping up the good work is a hard task. RSTS Engineering 
always tries to do what is best for the product and most 
of the time it is fun to do. Your job, which is also hard 
to do, is to keep us on the right track... 

W41) All - It appears we must convert or coexist with VMS if we 
are to tap any of the new products. RSTS/E has been and is 
a fine product meeting most of our needs in a very easy, 
friendly, secure way. My wish: Please so everything 
possible, with high priority to facilitate co-existence 
and conversion. 

A41) Digital is very concerned about continuing to meet the 
needs of its customers. 

For the RSTS customer, this need may mean coexisting with 
VMS cr it may mean an eventual migration to VAXes. V7e are 
currently planning tools (i.e., RSTS/E - VMS Compatibility 
Guide) to assist our customers with the process of either 
coexisting or migration. 

Digital is actively supporting RSTS/E and will continue to 


provide quality releases with emphasis placed on features 
that provide improved compatibility with VMS. (Tech. 3, 
Prod. 1) 

V43 Other - LOGIM should have the ability to record all login 
attempts that fail to the "access denied" point. 

Reason: Security 

A42) Thank you for your suggestion. We will look at it. (Tech. 
1, Prod. 1) [Ed. note - If you are running V9.x and not 
running OPSER f if you declare a message receiver named 
OPSERr it will receive all LOGIN/OUT console message 
traffic r which you may then store in a file and analyze. 
You may also have to modify LOGIN/OUT slightly to force 
logging for the job classes (local, dialup, net, etc.) you 
are interested in.] 

V, 4 3) Other. - LOGIN.COM should be moved off [0,1] and onto an 
account which is smaller and can be REORDRed. 

A43) We do realize there is a performance problem with logging 
into the system and we are looking at ways to improve the 
performance. Until then, you can continue to use PIP ' s 
/MODE:1536 to put LOGIH.COM at the top of [0,1]. We have 
not heard why that would not be sufficient. (Tech. 2, 
Prod. 2) 

W44) Other - TSRMGR should allow wildcards for KB #'s in the 
SET TERMINAL command. For example, SET TER KBG*:/AUTOBAUD 
/DIALUP. 

Reason: System startup is extended by having many 
(possibly) identical SET TER commands, reloading DCL & 
TSRMGR for each one. This would speed up system startup. 

A44) Because TERHGR w T ould have to go through all KB’s, it is 
not certain if this would speed up system startup. Put a 
"RUN STSRMGR" command before the first SET TERM command. 
[Ed. note - The 1987 SIG tape has a utility which creates 
a patch file containing most system defaults. Once 
applied, you will not need to specify the defaults again.] 

W45) Add a /SORT=(NAME!TYPE!SIZE!DATE) switch to the DIRECTORY 
command. Combinations should be allowed: /S0RT=(NAME,TYPE) 
would sort by name as primary and then by type.. This would 
be the default if only /SORT was specified. 

Reason: It would make locating files in the directory 
easier. 

A 4 5) Do a DIEECTORY/OUTPUT=f ile and then SORT the output file 
using the SORT command. (Tech. 3, Prod. 3) 

W4S) Other: Facilities to help the visually impaired - SET 
DOUBLEHIGH/DOUBLEWIDE - Hooks and utilities for DECtalk. 
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A46) This is a very reasonable request and it would be a nice 
feature. Thank you for your suggestion and we will keep it 
on file for future consideration. 

W47} Other - Ability to read the VAX CD disks - A handler or 
conversion program or both. (Tech. 3, Prod. 2; 

A47) You can hook up the CD disk to your VAX and copy the data 
across the netv?ork. (Tech. 0, Prod. 0) 

W48) Other - Directory should have the ability to net a list of 
files with only certain characteristics - in particular a 
public protection code, a priv protection code, and .marked 
for caching. 

Reason: System tuning and security. 

A48) This is a acod idea. We consider it difficult to do. 
(Tech. 3, Prod. 2) 

W49) Other - Is it possible to make SY3LI3.0L3 (or reasonable 
parts thereof) into a resident library? 

A49) Too many layered products that are task-built would have 
to be changed to warrant making this change. (Tech. 3, 
Prod. 2) 

W50) Other - I would like to get the source for HELP so that I 
could customize it. It could be in SOURCES: like SYSTAT 
and others. 

A50) You can do this by purchasing the source kit. [Ed. note - 
I think there was a small slip-up here. HELP was included 
in SOURCES: for V9.0, but when it was updated (in 9.3) it 
was left off the update kit SOURCES: account. According to 
a SPR answer I received , this will be corrected in the 
next release.J 


W51) Other - System callable routines for the creation / 
changing / deletion of symbols. 


A51) 

This is also technically difficult and 
long priority list. (Tech. 3, Prod. 2) 

falls low on 

our 

W52) 

Other - To have a class of terminals 
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dialup, for purposes of who can log in 
LOGIN logs the attempts. 

, and 
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A52) We hope to look at this for a future release. (Tech. 2, 
Prod. 2) [Ed. note - You can modify LOGIN/OUT to change 
the classes for which information is logged.] 

W53) Other - How about some way to quickly copy a tape to a 


TK50 and the ether way toe; 

A33) We do not understand this wish item. Please submit again 
with additional explanation. 


Why You Can’t Manipulate DCL Symbols 

Recently there has been a good deal of discussion about 
why you can’t manipulate DCL symbols from with a (r.cn-DCL) 
program. The following is a somewhat technical summary of the 
problems involved, as well as a pointer to some references if 
you really want to try it. Please remember that the opinions 
stated in it are my own, and don’t hold DEC responsible for any 
errors. 

RSTS DCL attempts to emulate VAX/VMS DCL in dealing with 
symbols. For applications coded entirely within DCL, it does 
admirably well in this emulation. However, users familiar with 
the VMS library routines for DCL symbol manipulation frequently 
wonder why RSTS/E doesn't support such routines. 

THE REASON: VMS supports a vastly larger address 
space for user programs. Therefore, giving up ' N' K for DCL 
symbols has utterly no effect. Similarly, the routines to 
manipulate the symbols can be contained in user address space 
without constraining the size of a user's program. 

However, on RSTS, users are squeezed against the hardware 
limit of 32Kw of instructions. Therefore, a design decision was 
made to place the DCL symbol table (and other context) in a 
workfile when DCL was not the current run-time., system. There 
were significant technical hurdles involved, mainly centered 
around not wanting to force the user to give up a channel for 
the workfile. 

The end result was to create a new set of 16 channels 
*just* for DCL' use. This is where the .COM file nesting depth 
limit comes from, and also explains why you give up a nesting 
level when using a logfile. These new channels can be opened, 
closed, read & written to, and SPEC'd just like normal 
channels. The only difference is where the channel information 
is kept. A new system call (UUO.PFB) was created to swap these 
channels back and forth between 'user context’ and 'system 
context'. 

Now that you know where it is and how to access it, you 
might be tempted to try looking for symbols in the workf ile. 
The next problem you will have is 'what is the format of all 
this stuff? ' If you define some text symbols, you may discern 
some sense of the format. The easiest thing to do would be to 
use the DCL symbol manipulation routines, no? 
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Unfortunately. you would have to switch run-time systems 
to get to these routines. Currently there exists no mechanism; 
for preserving program context across such a switch (ever type 
HELP from within BASIC-Plus and lose your program.?). Sc, the 
next idea you get is to incorporate these routines into your 
program. Unfortunately, your program is now too big to fit in 
the 32Kw limit! 

And that, in a nutshell, is why you can't manipulate DCL 
symbols from within application programs. 


Hardware Update Bulletin 

This section covers hardware updates pertaining to RSTS/S 
systems. 

The only news this month is that various type of power 
controllers may have incorrectly rated power cords. Apparently, 
the problem only manifests itself in fully-loaded RAS1 
cabinets. A quick way to tell if you have the problem is to 
look for 12 gauge wire (20 Amp rating) with a 30 Amp power 
plug. 


Software Problem Report (SPR) Log 

Please send the newsletter editor copies of any SPR 1 s (and 
Digital's answer) on RSTS/E, DECNET/E. or RSTS layered 
products. We will print any that are of general interest. The 
reason for this is that many SPR's are answered with a patch or 
a notice of restriction, but due to space considerations, they 
are not published in the Software Dispatch. Since we're 
desperate for material, this should be useful information and 
we will print it. 

The Newsletter system will be expanded in one near future 
to allow bulletin-board style messages to be posted for users 
to exchange this information, which should make it much more 
timely. 
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From the Editor: 

The submissions to the Minitasker this month were kinda scarce. Bob 
Walraven's FORTRAN SLATE shows how to get FORTRAN-77 programs to run 
as system jobs using as little of low memory as possible, and Rob Hamilton 
from Digital responds to an early FORTRAN SLATE column. Rob also gets this 
month’s "Obscure Bug of the Month" award for unearthing (and analyzing) a 

truly deep-hidden bug in one of the SIG tape programs. Even if you never 

use the program in question, you’ll want to know about this bug which could 
byte (!) you too, when you least expect it. 

Gary Sallee has submitted a very good article about using KERMIT/RT-11, but 
it arrived too late to get edited into this issue. (It was postmarked 

December 3, 1987 by U.S. Snail, and was delivered on March 24, 1988. The 
increase in postal rates is clearly to cover storage!) I’ll have to break it up, 

and it'll be serialized in the next two or three issues. 


All the usual caveats apply. It is assumed that anything you send is in the 
public domain or at least that there are no nasty copyrights being violated. 
I'm supposed to be sure that the "DECUS Commercialism Policy" is adhered to, 
so I wary of anything that looks like marketing hype or product 
announcements. (There’re several people beyond me who can override things 
I think can be printed.) There’s no problem with talking about technical 
aspects of your product (e.g. "how we did it") though. I especially interested 
in programming tidbits, hacks, bugs and fixes. 


Send stuff to: 

John M. Crowell 
RT-11 Newsletter Editor 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 


Camera ready copy is appreciated, and machine readable submissions are nice 
too. (I’ll return floppies - RX01, RX02, or RX50 please - I don’t have a RX33 
yet. RL02, TK50 and 9-track magtape are OK, but unlikely.) But it doesn't 
have to be so finished or polished. I've been known to accept hen 
scratchings on post-it pads. (It lets me feel that I'm actually doing some 
editing, after all.) I’ll be seeing some of you in Cincinnati this month, so 
expect me to hit you up for an article or three. 


Unless I get some input from you readers, I’ll be forced to start filling the 
pages with "My Favorite TECO Macros." So if you've got a little program you 
use to recover data from disks that have been scored by misaligned heads, or 
have managed to impliment the SET SYSTEM NOCRASH command, send me a 
page or two. The only thing more satisfying than stealing from your friends 
is sharing with them. 
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The FORTRAN Slate 

Bob Walraven 
Multiware, Inc. 


In this month's column we are going to present some VERY handy ways to 
build FORTRAN programs. You'll find out how to squeeze the last bit out 
of memory, and even learn how to build a FORTRAN program that runs as a 
system job with an itty-bitty root segment. A word of warning: these 
techniques are meant for the XM monitor only. If you don't use XM, read 
the column anyway - maybe you'll decide that its time to switch to XM and 
start realizing some of the real power of RT-11. Another caveat is that 
these techniques work with version 5.OA (and later) of FORTRAN-77, but 
probably will not work with version 5.0. On the other hand, we told you 
several months ago that you really should upgrade if you are still running 
5.0; so if you havn't yet, you might.'want to call your local Digital 
office right now. 

When a FORTRAN-77 program starts up, it first calls the OTS initialization 
routine OTI$. OTI$ builds the Dynamic Work Area (DWA) in memory to store 

o a buffer for formatted I/O 

o a channel table for locating the File Descriptor Block associated 
with an open unit 

o File Descriptor Blocks where pertinent information is stored for 
open units 

o I/O queue elements 

o I/O buffers for open units 

o Dynamically loaded handlers 

The items are stored in the order shown, starting from the highest memory 
location of the DWA except for dynamically loaded handlers and I/O 
buffers, which are allocated as they are needed from the bottom of the 
DWA. If the DWA is not big enough for the items that are stored from the 
top down, the job will exit. If the DWA is big enough for thee items, but 
does not have enough additional room for the handlers that are dynamically 
loaded or all the I/O buffers that must be simultaneously open, then the 
job will fail during execution. 

The actual location of the DWA will depend on how the job is built: 

o For a program with no virtual overlays and no virtual arrays, the 
user typically builds a privileged job (as opposed to a virtual 
job) by simply compiling and linking the program. In this case, 
OTI$ performs a .SETTOP starting from the top of the program to 
the highest available address (near the bottom of the USR), and 
uses all the memory obtained for the DWA. Since the highest 
available address can be significantly less than the available 
32K words of address space in the PDP-11 architecture, this mode 
is the most restrictive; programs built as privileged jobs can 


easily run out of memory, especially on the PRO. Furthermore, 
the highest available address will depend on which handlers and 
system or foreground jobs are loaded, so you might find that a 
program will only run if you unload enough stuff from memory. If 
the program will not run with the R or RUN command, however, it 
probably can still be run under the XM monitor with VBGEXE . This 
is one reason that the XM monitor is sometimes preferred by 
FORTRAN programmers. 

o If a privileged job is changed to a virtual job (using SIPP to 
set the VIRT$ bit in the Job Status Word), the program can then 
allocate all the memory from the top of the program up to the top 
of virtual address space (i.e., the 32K word boundary), but this 
may not help much, because a virtual job will not run with the R 
or RUN command if the top of the job is above the bottom of the 
USR. 

o If a FORTRAN-77 program on XM is linked with the module VIRTXM 

(required if the program has virtual arrays or virtual overlays), 
then VIRTXM preallocates the DWA in low memory. VIRTXM uses a 
default value for the line buffer length of 136. bytes and a 
default value for the maximum number of units of 6. You can 
change these default values by linking with the module F77DWA 
(shown below) placed after VIRTXM. For example, 

LINK myprog,SY:VIRTXM,F77DWA/XM. If you do this, be sure to 
compile your program with the corresponding switch values for 
UNITS and RECORD. 


.TITLE 

F77DWA 



Allocate FORTRAN-77 Dynamic Work Area (line buffer, channel 
table, I/O block buffers, etc.) in low mem psect. 

UNITS = 
LRECL = 
NS I ZE = 

6 . 

136. 

512.+40.+1. 


Maximum number of LUNs 

Line Buffer Length in bytes 

Bytes required for each LUN 

Size = buffer + channel table + LUB 

.PSECT 

$$OTSS,RW,D, 

, LCL,REL,CON 

: . BLKB 
.EVEN 

UNITS *NSIZE + LRECL 



$ IOBKL:: 


.END 
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The following program will allow you to see how the DWA is assigned when 
you link the program in different ways. 

PROGRAM ShoDWA 

implicit integer (A-Z) 

OTSbase * IAOTS () 

plnbuf = IPEEK ( OTSbase + 2 ) 

chnatb * IPEEK ( OTSbase + 4 ) 

filetb « IPEEK ( OTSbase + 6 ) 

qelem = IPEEK ( OTSbase + 8 ) 

devhdr - IPEEK ( OTSbase + 10 ) 

freesp - IPEEK ( OTSbase + 12 ) 

bend = IPEEK ( OTSbase + 32 ) 

limit - IPEEK ( OTSbase + '164'0 ) 

start = IPEEK ( limit ) 

top *= IPEEK ( limit + 2 ) - 2 

type 10 , freesp , devhdr , devhdr-freesp , plnbuf-chnatb 
10 format ( ' Start of free DWA at ',06 / 

1 ' End of free DWA at ',06 / 

2 ' Amount of free DWA = ',06 / 

3 ' Maximum units = ',06 ) 

if ( qelem ,ne. filetb ) then 

type 20 , qelem 

20 format ( ' I/O queue elements at ',06 ) 

end if 

type 30, filetb , chnatb , plnbuf , bend 
30 format ( ' File desriptor blocks at ',06 / 

1 ' Channel table at ',06 / 

2 ' Formatted I/O buffer at ',06 / 

3 ' End of DWA at ',06 ) 

type 40, start , top 

40 format ( ' Start of program = ',06 / 

1 ' Top of program = ',06 ) 

END 


.title IAOTS 

IAOTS is a FORTRAN-callable subroutine that returns the base address 
of the OTS impure data area. 


/ 

; Usage: 


I = IAOTS () 


.psect 

$CODEl,rw,i,lcl,rel,con 

IAOTS: : 

mov 

return 

$OTSV,rO 


. end 
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VIRTXM contains the virtual array initialization routine $VINIT that is 
called by $OTI. If you don't link with VIRTXM, a dummy $VINIT is 
automatically substituted from F770TS during linking. If you DO link with 
VIRTXM and your program contains no virtual arrays, then you will be 
wasting a little room by having the real $VINIT included in your . SAV 
image. This problem can be avoided by linking your program instead with 
the MACRO module VIRJOB: 

.TITLE VIRJOB 

; This module should be linked with a FORTRAN-77 program if a virtual job 
; is desired and the program contains no virtual arrays. 

} 

; Usage: .LINK myprog,VIRJOB/XM 

; The values of UNITS and LRECL below correspond to the default values 
; of the FORTRAN-77 compiler /UNITSrn and /RECORD:length switches. 

; If non-default values of these switches are specified, the values 
; of UNITS and LRECL should be changed accordingly. 

UNITS =6. ; Maximum number of LUNs 

LRECL *= 136. ; Line Buffer Length in bytes 

NSIZE = 512.+40.+1. ; Bytes required for each LUN 

,* Size = buffer + FDB + channel table entr 
QSIZE = 10. ; Size of XM queue elements 

.ASECT 
.=4 4 

.WORD 2000 ; Set the VIRTUAL bit in the JSW 


.PSECT $ $OTSV,RW,D,GBL,REL,OVR 

QBLK$:: .WORD $QBLK ; Location of queue elements 

VIRSZ$::.WORD 0 ? No virtual arrays 

IOBKF$::.WORD $IOBKF ; Start of dynamic area 

IOBKL$::.WORD $IOBKL-2 ; End of dynamic area 


.PSECT $$OTSS,RW,D,LCL,REL,CON 

$QBLK:: .BLKW QSIZE*UNITS ; Allocate 1 queue element for each unit 


$IOBKF::.BLKB UNITS*NSIZE+LRECL ; Allocate storage for linebuffer 

.EVEN ; and LUN tables 

$IOBKL:: 

.PSECT $ $OTSI,RO,I,LCL,REL,CON 
.MCALL .PRINT .EXIT 

$VINIT::RETURN ; Dummy virtual array initializati 
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$NOLXM:PRINT #NOLXM 
.EXIT 


Error if no /XM specified in LIN 


.PSECT $$OTSD,RO,D,LCL,REL,CON 


NOLXM: .BYTE 

.ASCII 
.BYTE 
.ASCIZ 
.EVEN 


15,12 

/Exiting due to ERROR 103/ 
15,12 

\VIRJOB needs LINK/XM\ 


.END 


Let r s take a moment to examine VIRJOB, because an understanding of its 
parts will be assumed below. 

o The maximum number of units and the length of the line buffer in 
bytes are specified so that you can set DWA to be exactly the 
length you need and no longer. If you have specified nonstandard 
values with the compiler switch /UNITS:n or /RECORD:length, then 
you need to change the values in VIRJOB to match the values you 
specified. 


Remember that a restriction RT-ll/XM imposes on virtual jobs is that the 
top of the root must be below the USR for the job to be runnable. This 
means that the bulk of your code needs to be in virtual overlay regions. 
However, there is another GOTCHA that really has a bite: the linker likes 
to put lots of F770TS and SYSLIB stuff in the root. Even if your root 
source is a one line subroutine call to the real code in a virtual 
overlay, it doesn't take much of a program before the root grows so large 
that the program won't run. What we are now going to present is a way for 
you to build your FORTRAN-77 programs so that the root is really small. 

Not only does this insure that your job will run, but it allows you to 
make FORTRAN system jobs that only use a little over 800 words of low 
memory. This means that you can have several FORTRAN system jobs, a 
FORTRAN foreground job, and a FORTRAN background job all running at the 
same time. Well not actually AT THE SAME TIME, but they can all be in 
memory at the same time with all but the one that is running in a waiting 
state. Thus if you have sufficient extended memory and run the XM 
monitor, it is possible to construct an application that consists of 
several large cooperating system jobs that are all in extended memory at 
the same time. 

The secret to building a FORTRAN system job is to split up the work done 
by VIRJOB into a root part and an overlay part. You'll need the two MACRO 
routines VROOT and VMAIN, shown below. 


o The VIRT$ virtual image bit in the Job Status Word by loading 
referencing the JSW directly in an .ASECT. 

o The psect $$OTSV must appear exactly as shown. The four words in 
this psect provide information to $OTI about the location of 
queue elements and the DWA. If you linked with VIRTXM instead of 
VIRJOB, then VIRSZ$ would indicate how much extended memory is 
needed for virtual arrays. 

o The psect $$OTSS must also appear exactly as shown. It contains 
space for the queue elements and space for the DWA. If your 
program calls system services that require additional queue 
elements, then you should add additional queue elements here by 
changing the contents of $QBLK accordingly. WARNING: Do not 
call IQSET in your program unless you have masocistic tendencies 
- you must declare all your queue elements in VIRJOB. Notice 
that the DWA is just big enough to contain the line buffer and 
one channel table entry, one FDB, and one 1 block buffer for each 
unit. 

o The psect $$0TSI is where most F770TS code is stored. This psect 
contains a dummy virtual array initialization routine ($VINIT) 
and an exit point that is called by $OTI if you forgot to use the 
/XM switch (or /V CCL switch) when the job was linked. 

o The psect $$OTSD is used to store common F770TS data. It 

contains the error message that is printed if you forgot the /XM 
switch 

Try linking the program ShoDWA in various ways, including with VIRTXM and 
VIRJOB to see how the DWA is allocated. 


.TITLE VROOT 

; This module acts as the root for a FORTRAN-77 program that is 
; to be linked as a virtual job of minimum size. 

; Usage: R LINK 

; myprog=VROOT// 

; VMAIN,mymain/V:1 

; mysegl/V:2 

; ~C 

; The value of UNITS below corresponds to the default value of the 
; FORTRAN-77 compiler /UNITS:n switch. If a non-default value of 
; this switch is specified, the value of UNITS should be changed 
; accordingly. 



UNITS = 

6 . 

; Maximum number of LUNs 


QSIZE = 

10. 

; Size of XM queue elements 


. asect 
.*4 4 
.word 

2000 

; Set the VIRTUAL bit in the JSW 


.psect 

$ $OTSS,rw,d,1 cl, 

rel,con 

$QBLK: : 

: .blkw 

QSIZE*UNITS 

; Allocate 1 queue element per unit 
; plus any others you need 

VROOT:: 

: call 

VMAIN 

; CALL necessary so as not to confuse 


.mcall 

.exit 

.exit 

; overlay handler 


•end VROOT 
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.title VMAIN 

; This module provides the main entry point for a FORTRAN-77 program 
; when it is linked as a virtual job of minimal size. 

; The values of UNITS and LRECL below correspond to the default values 
; of the FORTRAN-77 compiler /UNITS:n and /RECORD:length switches. 

; If non-default values of these switches are specified, the values 
; of UNITS and LRECL should be changed accordingly. 

UNITS =6. ; Maximum number of LUNs 

LRECL = 136. ; Line Buffer Length in bytes 

NSIZE « 512.+40.+1. ; Bytes required for each LUN 

; Size = buffer + FDB + channel table entr 

.psect $$OTSV,rw,d,gbl,rel,ovr 

QBLK$:: .WORD $QBLK ; Location of queue elements 

VIRSZ$::.WORD 0 ; No virtual arrays 

IOBKF$::.WORD $IOBKF ; Start of dynamic area 

IOBKL$::.WORD $IOBKL-2 ; End of dynamic area 

$IOBKF::.BLKB UNITS*NSIZE+LRECL ; Allocate storage for linebuffer 

.EVEN ; and LUN tables 

$IOBKL:: 

.psect $$OTSI,ro,i,lcl,rel,con 
.mcall .PRINT .EXIT 


o The program has 28k words of memory available. (The bottom 4k of 
memory is used by the root.) 

Try making your favorite FORTRAN-77 program into a system job and see how 
it behaves. I've tried this technique out on quite a few programs and 
have been very pleased with the results. One of the more exciting things 
I was able to do was to run two FORTRAN-77 system jobs that talked to each 
other through the MQ handler; I still had room left over to run a 
background job, even on the PRO. I've only encountered to problems making 
FORTRAN-77 system jobs. The first problem is that programs that called 
IQSET would crash (think about where the queue elements end up). This was 
easy to fix - I just allocated as many queue elements as I needed in VROOT 
and deleted the call to IQSET. The second problem was encountered when I 
tried outputing some graphics to the PRO screen using a package that uses 
the screen device registers. I had no problem mapping to the I/O page and 
producing the graphics, but the system crashed after the output was 
finished. A nasty problem with trying to do graphics on the PRO is that 
you must completely disable PI output to the screen and you must be sure 
to restore the screen device registers to their original state before you 
return control to PI, otherwise the system will CRASH. I'm almost certain 
that what happened was that RT-11 decided it was time to go to the 
background so it tried to output the B> prompt before my program was 
through with the device registers, even though I told PI to keep quiet. 

In the next column I will say a bit more about running FORTRAN-77 programs 
in this nifty way. I'll also show you how to map in the I/O page, in case 
you need to directly access device registers. 


$VINIT::return 

$NOLXMPRINT #NOLXM 
.EXIT 


Dummy virtual array initializati 


.psect $CODEl,rw,i,lcl,rel,con RESPONSE TO DECEMBER FORTRAN SLATE 

VMAIN:: 

.psect $$OTSD,ro,d,lcl,rel,con 

NOLXM: .ascii <15><12>/Exiting due to ERROR 103/<15><12> 

.asciz \VIRJOB needs LINK/XM\ 

. even 

From: Rob Hamilton 21-MAR-1988 14:32 

.end To: Bob, Walraven,John Crowell 

Subj: Letter for Minitasker, FORTRAN issues 

The root calls the subroutine VMAIN in the overlay segment. Since the March 11, 1988 

label VMAIN is at the very beginning of the psect $CODEl and your program 
main begins at the start of this psect, your program starts up at its 

not nisi enlty point. Try building ShoDWA with these modules. You will Dear Bob, 

notice the following advantages: 

In your "Fortran Slate" of December 1987, you raised several issues 

o The root contains only the queue elements, 3 words of code, and a re g ar di ng the status of FORTRAN-77/RT. First off, I apologize for 

small overlay handler. taking three months to respond. Unfortunately, on top of the problems 

that you mentioned, a new one has appeared; first in Europe, and now in 
o All F770TS and SYSLIB routines are put in the virtual overlay. our own u.S. SDC. In some cases, the 2nd disk of RX50 distributions of 

FORTRAN-77 V5.0A turned out to be a FILES-11 disk of some POS layered 
o The program can be run as a foreground or system job, and only product. This problem quickly assumed #1 priority, and we have 
uses 833 words of low memory. 
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resubmitted the correct original to the SDC. I have since verified that 
what the SDC has is the correct disk. Customers who received the 
incorrect RX50 disk should contact their sales representative. 

I'm not sure either, what happened to the original V5.0B that you 
submitted. In light of the recent V5.0A RX50 disk #2 master mixup, and 
the fact that you have since submitted a further improved F770TS, I have 
suggested to the FORTRAN-77 product manager that we hold V5.0B and 
submit the most up-to-date modules to the SDC, perhaps with a different 
version number. 

Next, I'll address the RT-11 SYSLIB routines that were moved between 
FORTRAN-77 OTS and SYSLIB.OBJ. As you pointed out, the first group of 
subroutines were removed from SYSLIB because they make direct references 
to FORTRAN OTS data structures. In some cases these references work 
with both FORTRAN-IV and FORTRAN-77. In others, they don't; there are 
specific versions of routines for FORTRAN-77, and they were originally 
supplied to FORTRAN-77 customers in SYSUPD.OBJ. The installation 
procedure replaces them in SYSLIB. The ones in SYSLIB were originally 
written for FORTRAN-IV, and are not relevant to other languages, 
including MACRO. We feel that they are now best maintained by the 
respective FORTRAN groups. It makes more sense that the routines 
specific to a FORTRAN OTS reside in that OTS. We would like for SYSLIB 
to evolve into a language-independent library. 

Much of the concern over this subject revolves around the customer who 
updates or buys RT-11 and does not update FORTRAN-77. The subroutines 
that were removed from SYSLIB were NOT deleted from the kits. Every 
distribution of RT-11 V5.4x contains and will continue to contain, a 
complete update of all layered products, including FORTRAN-77/RT. 

On the other side of the issue are the five routines that were moved 
from the FORTRAN OTS's to SYSLIB. These are DATE, IDATE, RAN, RAN$, and 
RANDU. These routines have no dependencies on either FORTRAN run-time 
system, and can be called by any language (using the FORTRAN calling 
standard). Customers who might suffer from this move are those who buy 
a new FORTRAN-77 compiler for use with an old release of RT-11. Any 
such customer who already has a distributed version of FORTRAN-77 V5.0 
or V5.0A can extract those modules from F770TS.0BJ and insert them into 
the new F770TS or SYSLIB. 

The idea behind these changes was to logically organize object modules 
in a way to make maintenance easier and more logical; not to trap people 
into buying one product or another. We are continuing to explore ways 
of making SYSLIB more robust and language-independent. 


John Crowell 

Editor, RT-11 Minitasker 
c/o Multiware Inc. 

2121B 2nd Street 
Davis, CA 95616 


March 21, 1988 


Jack , 


Recently, I obtained a copy of some DECUS submission tapes from 
Nick Bourgeois, and ran into an interesting problem with one of the 
savesets. 

The U.S. Spring 1986 tape has a logical disk called C2512B.DSK 
that contains LEX and some other stuff. Unfortunately, that logical 
disk has someone's FORTRAN program sitting in the home block, and the 
expression "I-IWRITW(256,BUFFI,BLKNO,OUTCHN)" appears such that the "BU" 
of "BUFFI" sits squarely in offset 252, which, as everyone knows, tells 
RT-ll's DIR program that this is a BUP disk (which it's not). BUP, 
being more particular, looks for "BUP", finds "BUF", and rejects it with 
"?BUP-F-Not a BACKUP volume". 

In order that a directory of this disk be displayed, one must first 
SIPP offset 252 of block 1 so that it contains zero. 

The bigger message is that if someone out there has a nifty program 
that makes logical disk files, that program should be modified so that 
all of the homeblock is initialized properly. There are indeed many 
logical disks on the DECUS submission tapes that have extraneous stuff 
in the homeblock. It can occasionally surface in the form of weird 
problems like the one described above. 


Regards, 

Rob Hamilton 
RT-11 Development 


Sincerely, 


Rob Hamilton 
RT-11 Development 
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Editor’s Springboard 

Yes. spring is in the air, even here in Southern California, where the uninitiated 
claim we have no seasons. Spring is here, can the Spring Symposium be far behind? 
Unfortunately, I cannot attend the symposium. For those of you lucky enough to 
be going, be sure to stop by the Unisig Suite, which will be shared, as usual, with 
Languages and Tools and Artificial Intelligence. Symposium travelers are probably 
focusing on Cincinnati right now, but how about last January's UniForum? I am 
interested in hearing from anyone who attended and had a look at A/UX - Apple's 
Unix offering. "They" claim A/UX is real unix with a user-friendly face. If anyone 
has seen it, or has it, or perhaps was a beta site, please drop me a line. 

This month we have a bit more variety than in previous months. We start with A 
Reader's Riddle , in which Daniel Fishman muses on Digital's commitment to the 
unix market. Next, we have another set of session notes that didn't make it into 
the published notes in Anaheim. This month's session is U039 - Enhancing the 
Digital Computing Environment through VMS/ULTRIX Connectivity. And finally, 
we have the winner of this month's Joke of the Month contest. There are two 
winning jokes, one winning entrant. Your comments, suggestions, articles are 
always welcome. Please send hardcopy to : 

Sharon Gates-Fishman 
NDC Systems 
730 E. Cypress Ave. 

Monrovia CA 91016 


or e-mail to: 


amdahl!cit-vax!ndc!sgf 
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A Reader’s Riddle 

by Daniel Fishman 


In August 1985 we received our microVAX II with 
Ultrix. Ultrix was perfect for our software developers, 
an environment with dozens of features and tools that 
make developing software easier. And Digital offered 
it on a new generation of machines that delivered an 
unprecedented price/performance combination. From 
the start it seemed digital wasn't really committed to 
Ultrix. Salespeople didn't know about it, software 
support was poor, and far more expensive than VMS 
software support. I brought these concerns to Digital's 
attention and was assured that Digital was committed to 
Ultrix and that DEC offered two operating systems 
(one of which I assumed was Ultrix) across the entire 
VAX line. Once I read a press report of some 
comments from an Ultrix product manager regarding 
LA VC (really lack of same) for Ultrix. He wrote me a 
nice reply telling me that he was misquoted and that I 
shouldn't believe everything I read. Well, the same 
irresponsible press is up to their old tricks again. This 
time misquoting Ken Olsen himself. I know he's 
misquoted because I deal with DEC every day 
regarding Ultrix. Isn't that commitment?. They 
helped me get my diskless workstations running Ultrix 
only three months after receiving hardware! And when 
I needed workstation documentation, they were kind 
enough to insists I receive an entire Ultrix doc kit in 
addition to my X documentation - committed, and 
generous. Seriously, I like DEC, and I like Ultrix. 
They sold it to me, I use it. I wish they acted like they 
liked and used it. If DEC treats UNIX the same way 
it treated personal computers, it will be to everyone’s 
disadvantage. As a customer I want to work with a 
vendor that can offer more than arm waving about 
support. DEC should either truly commit itself to the 
UNIX marketplace, or be truthful enough to suggest I 
locate another vendor who is in business to support it. 
In a future issue (assuming it gets by the digital police) 
will be my diskless workstation experience. 


Olsen Calls Unix 
‘Snake Oil’; Says 
It’s No Standard 

By Wayne Howe 

MARLBOROUGH, Mass. — 
What do Sun Microsystems Inc., 
Unisys, AT&T and others all 
have that DEC doesn’t? The an-, 
swer, of course, is an interest in 
the growth of Unix as an operat¬ 
ing system standard. 

“It’s like selling the Brooklyn 
Bridge—it’s absolutely snake oil,” - 
said DEC President Kenneth H. 
Olsen when asked at a press con¬ 
ference this-month what he thinks 
of Unix and technology-sharing 
agreements among competitors. 

Increasingly surrounded by 
companies that have staked their 
futures on users’ choosing the 
Unix operating system, DEC has 
felt the cost of its reliance on VMS 
rather than Unix more than once. 
The most publicized instance oc¬ 
curred last summer when DEG 
lost its fight to bid on a multi- 
billion-dollar Air Force contract 
because it lacked a defined Unix 
SVID product as required by the 
bid specifications. 

Olsen’s bitterness toward Unix 
is more understandable in the 
wake of other, more recent indus¬ 
try events. 

Just this month Unisys an¬ 
nounced that it was working with 
•SNAKE OIL,’ Page 93 
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Bridging ULTRIX and VAX/VMS 

A Working Proposal 

Ken Reilly, ULTRIX Engineering Group 


UNIX is a trademark of AT&T Bell Laboratories 
NFS is a trademark of SUN Microsystems 


Goals 

• Establish VAX/VMS and VAXclusters as the best 
resource server for ULTRIX/UNIX workstations. 
Exploit the enhanced availability, reliability, and 
price/performance provided by VAXclusters. 

• Bridge, don’t merge, server and client environment. 
Two target user groups: 

• Mixed VAX/VMS - ULTRIX Shop 

• ULTRIX/UNIX only Shop 

• Tracking the ULTRIX strategy and direction 
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Bridging ULTRIX and VAX/VMS 


Presentation Overview 

• Goals 

• Proposal Summary 

• ARPA Communication Subsystem Components 

• NFS Components 

• Feedback/Questions & Answers 


Proposal Summary 

Promote resource sharing between VMS server and 
ULTRIX workstation 

Components 

* ARPA Communication subsystem 

* NFS file server 
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Dridging ULTRIX and VAX/VMS 


ARPA Communication Subsystem 


Provide the intersystem networking facilities for 
Digital-supplied and customer applications 



— Ethernet — Physical/Data Link 

Layer 


NFS file server 


What is NFS ? 


Application protocol which provides NFS clients 
with remote, transparent file services 



/proj.A*!^ /proj.B 
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ARPA Communication Subsystem 

Foundation Goals 

• Provide Arpa Internet ‘end node’ implementation 
for Ethernet 

• Provide application services related to data ser¬ 
vices (NFS, FTP) 

• Provide application interface to network 

Follow on Goals 

• Provide complete ARPA application suite (SMTP, 
TELNET) 

NFS file server 

Foundation Goals 

• Promote data sharing between VAX/VMS and NFS 
clients 

• Provide NFS clients with same file service as any 
ULTRIX based server 


Follow on Goals 

• NFS client support for VAX/VMS 

• support for data conversion for non-stream files 

• support application interface to RPC and XDR 
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Oridcjing ULTRIX anti VAX/VMS 

NFS file server 

Foundation Goals 

• Mount 

• NFS 


Follow on Goals 

• Yellow Pages (YP) 

• Remote Procedure Call (RPC) 

• External Data Representation (XDR) 

• Lock Manager(LM) 

• Status Monitor fSM) 


NFS file server 

VMS file system 

NFS client mounts VMS directory onto his local file 
system 

LASSIE::LASSIE$DUAO:[SMITH] to /usr/vms/smith/ 
The VMS file 

LASSIE: :LASSIE$DUA0:[SMITH]TEST.TYPE;3 
is accessed from the NFS client as 

/us r/vms/smi th/test. type. 3 
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NFS file server 


Mixed VAX/VMS - ULTRIX Shop 


• Provide NFS clients with access to RMS StreamLF 
(VMS) files 

• files subject to VAX/VMS file system rules 

• clients limited by NFS protocol file system 
mode! 

• Provide FTP client and server on VAX/VMS to 
access ULTRIX workstations 


NFS file server 


ULTRIX/UNIX only Shop 


Provide NFS clients with access to 100% compati¬ 
ble ULTRIX/UNIX filesystem 


• Promote data sharing by providing VMS application 
access to these ULTRIX/UNIX files 
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Bridging ULTRIX and VAX/VMS 


NFS file server 

ULTRIX file system ODS strategy 

Each ULTRIX regular file stored as a VMS data file 

ULTRIX directory hierarchy and inode info stored in 
a VMS data file 


Bridging ULTRIX and VAX/VMS 


Additional Applications Services 


Provide VMS applications with callable service to 
return VMS file handle for a ULTRIX file handle 

Provide callable service to ‘import’ files into a 
ULTRIX file system 

Provide callable service to ‘export’ files into a VMS 
file system 

Provide system management utilities to cre¬ 
ate/delete modify ULTRIX file system 


The Joke of the Month 

We have two Jokes of the Month this month, both submitted by Mark 
Bartelt, a unix jokester from way back. Thanks, Mark. And to those of 
you who didn’t win this month, keep those e-cards and e-letters coming. 
Your name could appear in this spot next month - all it takes is a joke! 


Joke #1 

A master was explaining the nature of Tao to one of his novices. 

"The Tao is embodied in all software -- regardless of how insignificant," said 
the master. 

"Is the Tao in a hand-held calculator?" asked the novice. 

"It is," came the reply. 

"Is the Tao in a video game?" continued the novice. 

"It is even in a video game," said the master. 

"And is the Tao in the DOS for a personal computer?" 

The master coughed and shifted his position slightly. "The lesson is over for 
today," he said. 

(From "The Tao of Programming", by Geoffrey James, via Mark Bartelt) 
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"Joke #2" Beware ... Awful pun ahead. 

Once upon a time there lived a fearsome troll named Og. So nasty and 
uncivilized was he that he refused to wear clothes; he stomped around the 
village completely nude, scaring the children and embarrassing the quiet 
townsfolk. 

Down the road from Og’s cave was a DEC sales office. It was only two 
weeks before the end of DEC’S fiscal year, and all the DEC salespeople were 
in a panic, for they were far short of their quota for the year. Especially 
were they short of sales for their Unix-based software for VAXes, yclept 
"Ultrix". For most potential customers were suspicious, saying, "That 
soundeth like a name for a brand of leggings.” So they were desperate to 
make even one more Ultrix sale. 

Suddenly an idea occurred to the youngest DEC salesman in the office, 
yclept Harold the Slow. "Why don't we try to sell a VAX Ultrix system to 
Og?" he exclaimed. "After all, he has much treasure stored in his cave, so 
we can offer him an attractive cash discount. And a good all-DEC VAX 
system will surely help him with tax accounting for his bridge toll franchises." 

"A wondrous suggestion!" said his supervisor, yclept Arnold the Superfluous. 
"Why don’t you bring in Og for an Ultrix demo? I'm sure we can make the 
sale right on the spot." 

So Harold the Slow went up the road to Og’s cave, and after much flattery 
and persuasion convinced Og to come into the DEC sales office for a paws- 
on Ultrix demonstration. All went well for a while; Og was familiar with 
secret passwords from his dealings with wizards and elves, and he was soon 
logged in at a terminal and ready for more. 

But soon confusion set in, for though Og was large of body he was rather 
small of brain. "Awk?" he said. "Grep? Nroff?? Mkdir??? This be not 
software, this be Black Magic, and you be tools of the Dark Forces." Og 
stood up in a rage, and with a swipe of his paw sent the terminal crashing to 
the floor. Then, lashing about him with both paws, he laid waste to the 
entire office, finally crashing through the machine room to strike deadly 
blows at the VAXes therein before bursting through the wall and stomping 
off to his cave. 

Harold the Slow and Arnold the Superfluous slowly picked themselves up 
from the rubble of their office. Looking at his underling ruefully, Arnold 
could only mutter, "We really should have known better ... After all, 
everyone knows that you can’t teach a nude Og Ultrix!" 

(Originally posted to the net in 1984; sent in by Mark B arte It, who got it from 
Norman Wilson, who got it from Roseann Maclean.) 
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DECUS PROGRAM LIBRARY 


ANNOUNCEMENT: 

“Take special notice of the VAX SIG Collection from the Fall 
1987 Anaheim Symposium. DECUS Part No. V-SP-70. which is 
announced in this report This is the first SIG collection to be 
offered on three 2400’ Magnetic Tape reels at 1600 BPI. The 
DECUS Library is also going to make this collection the first one 
to be offered on one 2400’ Magnetic Tape reel at 6250 BPI .As a 
result of these changes, new media sendee charge codes have 
been established. They are as follows: 

MEDIA (SERVICE CHARGE CODE) PRICE 

(PD) 2400’ Magnetic Tapes at 1600 BPI S 190.00 

(SD) 2400’ Magnetic Tapeat 6250 BPI S 175.00 

NOTE: These prices are effective from now until July 2.1988. A 
new price list will be distributed at that time. 

The VAX SIG Collection will continue to be offered on the pop¬ 
ular TK50 tape cartridge, media sendee charge code (TC). 
Corrections to programs that have been announced through this 
report 


[ARC] 

|.BASSETT] 

I.BATTELLE] 

I.BZL] 


I.CI] 


|.CLEMENT] 

I. CLIB] 

J. COSTELLO] 
l.CSDHBO] 


Print on Hewlett Packard LaserJet includes 
forms. EVE Plus updates. 

Loan and investment programs. Watch¬ 
dog. FORTRAN menu system. Autodialer. 
Talaris fonts. VT241 colorset 
ARGNUM - Find number of args. User UIC 
change SYS sendee Filename from FID. 
Locate by size. UIC. etc. Hashed password 
save/restore. Structured MACROS. 

LSE templates for RUNOFF and LSE. 
Sample for outgoing connection to PSI. 
Erlang blocking formulas. Programs to 
measure real VAX CPU speed. 

Close VMS Accounting. Record counter. 
Dialup set Paginate docs. FORCEX force 
exit Reminder print 
Bonner RUN OFF (large superset of DSR). 
Continuous system status. 

Non-Digital Equipment Corporation C lib¬ 
rary and a few utilities using it 
Update (minor bugfix) to TPC. tape -] disk 
-J tape copy. 

Filter repetitive broadcasts on consoles on 


DECUS No: VAX 6 
DECUS No: UX-SP-101 
DECUS No :UX -101 
DECUS No :UX-102 
DECUS No :UX-103 
DECUS No: UX-104 


Add: "Software Required:VAX C 


cluster. 

Compiler" 

I.DJM] 

Elect. Telephone book: run AUTHorize in 

Add: “Software Required:VAX C 


any directory. Define VT2xx keys. INFO 

Compiler" 


re identifier. Tell what files will be purged. 

Add: "Software Required:VAX C 


See who uses a CMD procedure 

Compiler” 

[.DOLGEN] 

Utilities to ease conversion to DECalc V3.0. 

Add: "Software Required WAX C 

I.DOWNJ 

DOWN - utility to move around directory’ 

Compiler” 

tree. 

Add: "Software Required WAX C- 

[.DTREDIT] 

Utility to ease editing DTR fields w/o FMS 

Compiler” 

or TDMS. 

Add: "Software Required WAX C 

[.DTRSIG] 

ACCOUNTING - convert VMS Account¬ 

Compiler" 

ing to something DTR can handle. Also 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

VAX/VMS FAMILY OF COMPUTERS 

DECUS No: V-SP-70 Title: Symposium Collection from the 
VAX SIG, Fall 19S7. Anaheim Version: 1. February 1988 

Author: Various 

Submitted by: Glenn C. Everhart Ph.D. 

Operating System: VAX/VMS Source Language: BLISS-32. C, 
FORTRAN 77. MACRO-32. PASCAL. VAX BASIC. VAX FOR¬ 
TRAN Keywords: Symposia Tapes - VMS 

Abstract This is the VAX SIG tape from the Fall 1987 DECUS 
Symposium in Anaheim. The programs have been placed in 
three major directory structures named. VAX87C. VAX87D and 
VAX87E. The following is a brief summary of highlights: 

VAXS7C 

] ANLJOHNO] DCL interface for auto SUB single CMD 
batch jobs. VMS EXEC server symbiont 
DECnet SGETxxI server. Memory virtual 
disk driver much more efficient than PD- 


|. ELLIS] 

I.EROS] 

I.EVEUPDS] 

I.FLECSVMS] 


{.FLOWERS] 


[.GAMES] 


terminal meas. proc. ALL-IN-1 - I)TR 
definitions for A1 files. CORFU ONE - cor¬ 
porate phone directory in DTR. FUNC¬ 
TIONS - more DTR functions including 
spawn and string length. NEWSLET¬ 
TERS. PLOTS. CMI) Recall. SYSUAFdefs 
for DTR. more. 

Numerous kernel mode programming ex¬ 
amples. Such items as show process/files, 
purge workset of a process etc. 
BATCHACC - set account of batch job. 
CPU hogs monitor. Limit sessions/user. 
Password reuse disallow. 

Update to EVEPlus. DECUS Program No. 
VAX-150. 

FLECS and ALECS structured prep¬ 
rocessors for FORTRAN and MACRO. Now 
totally native mode. 

Delete zero length files. Show disk space. 
Move around directory tree and/or draw 
tree. EI)T files and wildcard editing. Mail 
UAF tools. 

HACK game from Dean Grover and ('RIB 
game from MN VAX LUG. 


DRIVER 


I. GRC] 

| .GROVER] 

| .HOWE] 

J. JCSLUG] 

].KETECH] 

|.KKA| 

I.LATSHAW] 

VAX87D 

I.COYj 


|.LEVINE] 


I.RCAF87] 


|. SEWELL] 

VAX87E 
|. LI LUG] 

I.MATUSCAK] 

|. MEADOWS] 


|.MERRIMACK] 

|. MI VAX LUG] 


CALC2SMG- Hewlett Packard calculator 
emulator. MODOBJ - fixup VMS object 
file 

Extensions to EVEPlus. SWING directory 
management program. 

EVE extensions. 

SETUSER- Become another user. Mailutil 
- check if your mail is read. Fast symbol 
definitions at login. Load foreign tapes. 
Mail system built on VAXNET. 

Standard menu interface software. SET- 
USER. 

Foreign tape reader. EVE extensions. 

VMS_SHAR to mail files through NETS. 

EDTEM - very extended EDT emulator 
in TPU. 

DM - directory manager. SD - set default 
program. WPS-PLUS emulator in TPU. 
Color setup forVT241. WPS-PLUS emulator 
for LSE. MCL -multicolumn file lister. 
NOTES update utilities. 

Extended accounting utilities. Cookie util¬ 
ity. INDEX - powerful FORTRAN cross 
referencer and static analysis. JUICER - 
Online and offline disk compression and 
file defragmenting. MUTEX-find sources 
of MWAIT states. NETLIST -condensed 
SHOWNET listing. QUICFONT - font 
editor for Talaris printers. System SNAP¬ 
SHOT. Card image tape read/write. Con¬ 
vert MACpaint to Talaris bitmap. 

AMIGA editors and utilities. AnalytiCalc 
for AMIGA. VAX, RSX IBM PC, Listrs 
multicol print. RIMS DBMS DOC update. 
Desktop Calendar. FINGER update LZW 
compress/decompress. Numerous utilities 
from Arpanet newsgroups, indexed. SCI 
SUB package w/docs. TAR read/write 
VMS Disassembler (EXE -j MAR). More 
MWEB - WEB adapted to Modula 2. WEB- 
MERGE - merge multiple change files. 
SCANTEX. 

No processes versus time plot. VT100 
demo. 

WANG IIS WP document conversion to 
MASS-11. 

FI LE - Change RMS attributes or dates on 
any files without copy. INDEX - find files 
based on several criteria (size, length, date 
fragmentatioa etc). FAST. STATUS- fancy 
SHOW USERS plus DECnet info. VERB - 
decompiler for DCL tables, converts to 
CLD. 

BATCH - CMD proc to generate Batch 
jobs interactively. Directory sharing util¬ 
ities. Find LAT terminal location. Super 
TPU edit 

PRIVILEGE - set/reset privs in menu 
fashion. CALCULATOR - SMG based cal¬ 
culator. GETQUI - get queue info. SWING 
rewrite from Digital Equipment Corpor¬ 
ation. 


I.MNVAX] 


|. NANNY] 

[.NDS] 

[.NEWS_SRS] 

[.NSTL] 

[.NSWC] 

I. PAGESWAPPERJ 

[.PERFMON] 

(.PICCARD] 

[.REMPRINT] 

[.RESTORE] 

|.RWK] 

J. RSXFINGER] 
[.SCHUMANN] 


[.SEALUG] 


[.SMITH] 

[.SOFTQUO] 

[.SPENCER] 

[.SYSMON] 

[.TULUG] 


[,T_NI ELAND] 


Key input in BASIC. Password change for¬ 
cer. Video Attribute Text Formatter. Ex¬ 
tended EVE. Statistical program. Edit/- 
RUNOFF control. Let privileged user be¬ 
come invisible 

Powerful system management aid' idle term 
killer/priority monitor. 

Fast spelling checker. 

Un*xN EWS rewritten for VM S: the celeb¬ 
rated Geoff Huston NEWS program. Han¬ 
dles USENET newsgroups on VMS. 
SETDEF - set default program. FRED - 
powerful editor, complete but written in 
TPU. FLEXISMB -print symb. 

BATCH - “instant" BATCH commands. 
MAILUAF maint. Appointment REMIN¬ 
DER. Execute on OTHERNODE (DEC¬ 
net.) 

“Pageswapper" issues since Spring 1987 
Symposium. 

VMS Performance Monitoring. 

EDT TPU enhancements. 

REMPRINT - print one or more files on a 
remote system device. 

RESTORE - recover deleted files from 
Files-11 ODS-2 disks. 

DTR system management aids. PASCAL 
environment files. 

FINGER utility for RSX: talks to VMS 
FINGER 

ARCHIVE - Procedures to archive disk 
directories to tape INCREMENTALS - 
locate which tape contains a file OPRES- 
POND - method to do two way COMM with 
operator WPS - WPS-PLUS emulator un¬ 
der TPU. 

MACINTOSH - read MAC files on VAX: 
file transfer. DECNET - conversational 
DECnet object Remote print batch con¬ 
trol; remote command exec. Build share¬ 
able .EXE. XMODEM and MODEM7 COMM 
programs. 

Remote print and form control over DEC¬ 
net 

Soft Quota disk management system. 
EDT enhancements (including WPS key¬ 
pad). EDTINI examples. TECO emulator 
for EDT. LSE section file implementing. 
Multiple process monitor utility to watch 
paging. 

Menu program in COBOL Amortization 
program. Define logicals from a central 
file. Give text of VMS ERR numbers. EDT 
enhancements. Purge working set LG02 
control files. REMINDERS. Operations 
help libraries. Save/restore recall buffer. 
Text library menu. More. 

EDTPLUS - EDT emulator in TPU with 
many additions. SEND - broadcast short 
message to other user. SETDEF - IN foreign 
utility. WSLTEX - Wordstar to LaTex 
filter. 


LIB-1 


LIB-2 



j.UALR] BBS - FULL function BBS system for VAX 

(MSG. conferences, uploads, downloads). 
CB- CB simulator for VAX. ETAPE- read, 
write EBC/ASCII tape. OPERMENU - 
menu driven operator system. WHO - 
cluster-wide who's on the system. 

[.VFE] VAX File Editor, binary/hex/ASCII. EBC¬ 

DIC. etc., disk or file editor. 

|.\T2XX] Program VT2x.\ function keys F6 to F20. 


[.WATSON] EVE and EVE Plus extensions includes 

Dennison speller interface DIRED. 
[.WOLFE] Extended EVE with simple spell checker. 

Print Symbiont 

Complete sources may or may not be included. 

Media (Service Charge Code): 2400’ Magnetic Tapes (PD) 
Format VMS/BACKUP, 2400’ Magnetic Tape (SD) Format 
VMS/BACKUP, TK50 Tape Cartridge (TC) Format VMS/ 
BACKUP 


DECUS No: V-SP-71 Title: Symposium Collection from the 
RSX SIG, Fall 1987, Anaheim Version: 1. February 1988 

Author. Various 

Submitted by. Glenn C. Everhart 

Operating System: IAS. MICRO/RSX. MicroVMS. P/OS. RSX- 
11M. RSX-11M-PLUS. RSX-11S. VAX/VMS Source Language: 
C. FORTRAN 77, FORTRAN IV-PLUS. MAC Rail Keywords: 
Symposia Tapes - VMS 

Abstract This is the RSX SIG Tape from the Fall 1987 DECUS 
Symposium in Anaheim. It is available in either BRU format or 
VMS/BACKUP format. See DECUS Program No. ll-SP-99 for 
a description of the program. 

Complete sources may or may not be included. 

Media (Service Charge Code): 2400’ Magnetic Tape (PS) For¬ 
mat VMS/BACKUP. TK50 Tape Cartridge (TO Format VMS/ 
BACKUP 


DECUS No: V-SP-72 Title: AMIGA Utilities Collection 3 Ver¬ 
sion: 1. February 1988 
Author Various 

Submitted by. Glenn C. Everhart 

Operating System: AMIGA DOS, VAX/VMS Source Language: 
ASSEMBLY. BASIC. C. FORTRAN77, MODULA2 Keywords: 
Data Base Management, Games, Graphics. Utilities - VMS 
Abstract This tape contains a large collection of utilities and 
programs for the AMIGA 32 bit computer. The AMIGA is an 
inexpensive machine well suited to be used as a powerful graphics 
workstation in a Digital Equipment Corporation host environ¬ 
ment with multitasking, large address space, windows, graphics, 
color, and more 

The tape contains some new and improved VT100 emulators, 
editors. CAD programs, database software, games, picture pro¬ 
cessors. code to let an AMIGA be a part of Usenet drivers, music 
players, and scores, multiwindowing remote host packages, 
hard disk backup utilities, new fonts, appointment keepers, a 


BBS. CLI frontends. instructions for a simple AMIGA based 
hypertext system, animations, plotters, disk catalogers. cal¬ 
culators. Prolog interpreter, and more. 

This package contains items introduced for AMIGA PD con¬ 
sumption since the “AMIGA Utilities Collection 1”. DECUS 
Program No. V-SP-6S. and “AMIGA Utilities Collection 2". 
DECUS Program No. V-SP-69. tapes became available. Numer¬ 
ous source programs make these programs valuable even on 
non-AMIGA computer configurations. 

Because many of the files are in .ARC form, the VMSSWEEP 
utility is provided to allow for examination of these archives 
online on a VAX under VMS. An executable version of the ARC 
utility for VMS is also provided. However, since this is an alpha 
version of VMS ARC. it has several limitations which make it 
less able to read archives under VMS than VMSSWEEP. This is 
why both are provided. 

Complete sources may or may not be included. 

Media (Serv ice Charge Code): 2400’ Magnetic Tape (PC) For¬ 
mat: VMS/BACKUP, TK50 TapeCartridge(TC) Format VMS/ 
BACKUP 

DECUS No: VAX-302 Title: TELLFOR Version: 1.0. January 
1988 

Author Ed Carraway. CDI. 1916 Sam Rittenberg. Apt 1716, 
Charleston. SC29407 

Operating System: VAX/VMS V4.5 through V4.7 Source Lan¬ 
guage: VAX FORTRAN Keywords: Mail. Utilities - VMS 

Abstract: TELLFOR is modeled after the VMS utility REPLY. 
It does not necessarily have to be used in conjunction with 
operator functions because it is installed on the system as a 
privileged image. Thus, all users can take advantage of the 
SBRKTHRU system service without having the responsibility 
of added privileges. TELL differs from REPLY by several fac¬ 
tors. such as: 

• It will not (without slight modification) notify all users simul¬ 
taneously. 

• It automatically rings the terminal bell, and also puts the 
message in bold video. 

• It cannot be used in an operator reply/request context. 

• It can grab the user’s attention by blinking the terminal 
screen from normal to reverse (TELL/REVERSE). 

• It can defer a message until a certain date and time (TELL/ 
AFTER=). 

• It can display the message in double-size text (TELL/ 
LARGE). 

• The REPLY/USER= and REPLY/TERMINAL- are incor¬ 
porated into the one command TELL If the breakthrough is 
unsuccessful in locating a user, it will search for a terminal. 

It should be installed with the procedure TELL_INSTALL COM. 

or this procedure should be closely followed. 

The author welcomes any questions or comments. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) For¬ 
mat VMS/BACKUP 


DECUS No: VAX-313 Title: MANAGEMENT TOOLS Ver¬ 
sion: 8.802. February 1988 

Submitted by: M.D. Smith. Smith Broadcasting. Inc.. Huntsville. 
AL 

Operating System: VAX VMS V4.6 Source Language: VAX-11 
BASIC Keywords: Business Applications. Utilities - VMS 

Abstract: MANAGEMENT TOOLS is a series of ten programs 
and a text file written by a manager with twenty-five years 
experience as a manager, including ten years teaching manage¬ 
ment seminars. The entire program is MENU driven as you 
RUN the program MENU.EXE. VAX BASIC (.BAS). .OBJ and 
.DOC files of each program are also included. The. DOC files can 
be read from the main menu. 

• CO.MMUN.EXE Communication effectiveness 

• DECTSI.EXE Decision making help 

• DELEGA.EXE Be a better delegator 

• EVALUE.EXE Employee evaluation 

• GETDUN.EXE Getting more done in a day 

• MANAGE.EXE Better overall manager of people 

• MOTIVA.EXE Motivation of people and self 

• MYBOSS.EXE Boss evaluation program 

• PLANS.EXE Planning improvement 

• TIMEFI.EXE Time management improvement 

• INTERV.QES Interviewing prospective employees 

The more times a manager uses these programs, the more 
benefits he: she will gain. There are options for hardcopy prin¬ 
touts of various portions of the programs as they run or they can 
be stored in files. 

These programs were originally written on an MS-DOS PC and 
were further modified to run on aC-64 and an APPLE computer. 
The BASIC code used is highly transportable for this reason and 
will run, with only minor modifications, on any computer that 
runs BASIC. As requested by the author, this program is not to 
be redistributed for profit of any kind. 

Non-management personnel will also find benefits in these pro¬ 
grams for business and private lives. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) For¬ 
mat VMS/BACKUP 


DECUS No: VAX-319Title: COBOLCross Reference Version: 
1.0. February 1988 

Submitted by Chester Czulada. E.F. Houghton & Co.. Valley 
Forge. PA 

Operating System: RSX-11M. RSX-11M-PLUS. VAX/VMS 
V3.0 - V4.7 Source Language: COBOL74 Keywords: Cross- 
Referencers 

Abstract COBOL CROSS REFERENCE is a COBOL program 
that reads the file created from the directory/out= TEMPI:- 
SRDCOBOLDAT command. This file directs the program to 
read the COBOL files in a directory assign to “COB:". All 
COBOL programs are scanned for file names in the SELECT 
statements and for the use of the COPY verb. 

Three report sections are produced: 

• SECTION A - PROGRAMS WITH ASSOCIATED FILE 
NAMES 

- Each COBOL program is listed with all the file names 
used by the program. This allows a quick review of the 
program files without access to the COBOL source 


• SECTION D - FILE NAMES - CROSS REFERENCE 

- Each file found in the COBOL programs is arranged 
alphabetically in this cross reference section. This is a 
very quick reference to which user programs have 
access to specific data files. 

• SECTION Y - COPY VERB USES - CROSS REFERENCE 

- Each COPY verb use is listed in alphabetic sequence 
with a cross reference to the program. 

The only requirements for this program are the three assign¬ 
ments for data areas. 

COB: COBOL SOURCE AREA INPUT 

TEMPI: DIRECTORY/OUT=TEMPl:SRDCOBOLDAT- 

FILE AREA 

RPT: REPORT OUTPUT ASSIGNMENT 

By limiting the directorv/out option file enables you to look at 
only specific systems for cross referencing. 

Example: Cross reference ap* programs only S directory/ 

out= tempi :srdcobol.datcob:ap*.cob $ run COBOL-CROSS_- 

REFERENCE 

Documentation may or may not be on magnetic media. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) For¬ 
mat: VMS/BACKUP 


DECUS No: VAX-320 Title: VCR—.FILES Version: February 
1988 

Submitted by Gail I. Schuman, Photon Research Associates 

Operating System: MicroVMS V4.5 - V4.7 Source Language: 
VAX FORTRAN Software Required: VAX FORTRAN Hard¬ 
ware Required: Starbuck8232 Data Acquisition and Control 
System Keywords: Data Communications, Device Handlers, 
Engineering Applications. Scientific Applications 

Abstract: VCR_FILES is a set of four subroutines written in 

VAX FORTRAN to communicate with the Starbuck 8232 in 
order to control a JVC single frame recording subsystem. Rou¬ 
tines are available for initializing the device (port) and com¬ 
munication channel, turning the unit “on” for a user-specified 
amount of time, turning the unit “off’ for releasing the device 
and channel back to the system. Although this software is 
device and system specific, it is easily modifiable and could be 
used as an example for programming similar devices. 

The routines are written in VAX FORTRAN, but are callable by 
either a VAX C or FORTRAN program. The routines all contain 

system service calls. The routine. VCR_ON is used to turn on a 

VCR through the Starbuck for a specific length of itme and then 
turn it off. This could be modified for any length of time. 

Media (Service Charge Code): One RX50 Diskette (JA) For¬ 
mat: VAX/ANSI, 600’ Magnetic Tape (MA) Format: VAX/ 
ANSI 


DECUS No: VAX-322 Title: VAXstation Games Version: 1.0, 
January 1988 

Submitted by: Charles Bulkeley 

Operating System: MicroVMS V4.5C Source Language: C 
Memory Required: 1MB Keywords: Games 
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Abstract This tape is a collection of games and graphics demon¬ 
strations for the VAXstation. Among these is a simulator that 
lets the user fly a three dimensional wireframe helicopter. Also 
included is a pool table game that lets two users play a game of 
eight ball. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) For¬ 
mat VMS/BACKUP 


DECUS No: VAX-321 Title: QMON Version: 1.0. February 
19SS 

Submitted by: Gardner Buchanan, C.F.S. Pacific Forestry Cen¬ 
tre. Victoria, BC. Canada 

Operating System: VAX/VMS V4.6 Source Language: VAX 
FORTRAN Keywords: Utilities - Disk - VMS 

Abstract When disk space suddenly becomes scarce, it is often 
hard to answer the question. “Who has used up the disk space?". 
This program builds upon the function of DISK QUOTA to pro¬ 
vide a way of tracking disk storage allocation by each user in 
addition to the simple snapshot. By comparing a user's current 
resource usage to his recent average resource usage, increasing 
or decreasing trends can be seen and the system manager may 
focus , his attention on users whose resource allocation is in¬ 
creasing. 

Notes: Operating system VAX/VMS V4.X and later is required 

Media (Service Charge Code): 600’ Magnetic Tape(MA) For¬ 
mat: VMS/BACKUP 

NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PDP 11 COMPUTER FAMILY 

DECUS No: ll-SPr99 Title: Symposium Collection from the 
RSX SIG, Fall 1987. Anaheim Version: 1, February 1988 
Author: Various 

Submitted by: Glenn C. Everhart 

Operating System: IAS, MICRO/RSX. MicroVMS. P/OS, RSX- 
11M. RSX-11M-PLUS, RSX-1 IS, VAX/VMS Source Language: 
C. FORTRAN77. FORTRAN IV-PLUS, MACRO-11 Keywords: 
Symposia Tapes - RSX-11 

Abstract This is the RSX SIG Tape from the Fall 1987 DECUS 
Symposium in Anaheim. It is available in either BRU format or 
VMS/BACKUP format The VMS tape is DECUS Program No. 
V-SP-71. Following are brief descriptions of the contents of the 
directories on the tape Common documents are found in direc¬ 
tory [300,1] and tape copy utilities are found in directory 
[300.2], 

[200.1] Mandelbrot set explorer and Graphic Mic¬ 
roscope for Digital Equipment Corpora¬ 
tion PRO 3xx. Submitted by R.J. Wilden: 
minor update by G. Everhart 

[240.1] The King James version of the BIBLE. 
Unlike previous versions, this one is in 
mixed upper and lower case; much easier 
to read than the earlier submissions. 

[265.1] Set/reset/show global event flags. Com¬ 
mand line editor. Send/receive packets from 


command. Also, utility to show or delete 
send/receive and send/recv-by-ref pac¬ 
kets (handy when pool gets cluttered...). 
Submitted by Hans Hamakers. DECUS 
Europe. 

[300.117] FMS-11 enhancements. Adds runtime video 

attribute control and read-with-timeout 
for single character fields, for FMS-11 2.0 
and 2.1. Submitted by Joseph Kulaga. 

[312.41] Update to LISTRS multicolumn lister for 
RSX Adds support for PIP type wildcards, 
line numbering, and many more new fea¬ 
tures. Submitted by Chris Doran. SIRA. 
England. 

[312.42] WLDCRD and ENTAB - utility programs 
for improved wildcard file handling and 
tabbing (replacing multiple spaces with 
tabs as appropriate). 

[312,315] Scientific Subroutine Package, with docs. 

The complete SSP math and statistics pac¬ 
kage is presented for Digital Equipment 
Corporation machines, with all comments 
and documents in the sources so they can 
now be more readily accessed. 

[312.350] Desktop Calendar. Appointment and sche¬ 
dule keeper version for PDP-11 complete 
with tested task images. Submitted by 
Mitch Wyle and Glenn Everhart 

[312.351] MicroEmacs 3.9e. These are the sources in 
C and all documents for MicroEmacs 3.9e. 
They need some work to port to PDP-11, 
but should be compact enough to do this 
with. MicroEmacs is a powerful but com¬ 
pact editor which can be customized for 
most needs. 

[327,2] INUSE - lock terminal for up to ten minutes 

when you need to leave it briefly. VT200 
and TEK4010 - toggle VT2-10 between 
VT200 and TEK modes. ALIAS - secure 
way of defining a user alias (including pass¬ 
word) for another system on DEC'net Sub¬ 
mitted by Arnold DeLarisch. 

[327,100] Floppy Disk copier. Copies between floppy 

disks and disk container files, format in¬ 
dependent 

[332.12] Bonner Lab RUNOFF, a large superset of 

Digital Equipment Corporation Standard 
RUNOFF. One of the best text formatters 
available on RSX. Submitted by John Cle¬ 
ment, Rice University. 

[343.120] BYE. TIMOD patches for secure CLI on 
RSX-11 M-PLUS. Submitted by Jim Bost- 
wick. 

[343.121] BYE. TTMOD patches for secure CLI on 
RSX-11 M-PLUS. Submitted by Jim Bost- 
wick. 

[343.122] SecureCommand Line Interpreter. Allows 
you to control what a non logged-in ter¬ 
minal can do. and provide a reasonably 
secure password system. Submitted by 
Jim Bostwick. 


LIB-5 


[343.123] Ancillary Control Drivers; one for elec¬ 
tronic scale, one a skeleton to roll your 
own... gives you fine grain control over ter¬ 
minal line protocols. Submitted by Jim 
Bostwick. 

[343.124] Convert between 64 bit integers and DTR 
clunk date' times. Also. 64 bit integer math 
routines. Submitted by Jim Bostwick. 

[351.144] Papers giving tutorials on RSX. P OS. and 

RT-11 indirect command languages and 
some utilities for use with indirect includ¬ 
ing case conversion. .STB dumper. BRU 
preprocessor. CDA preprocessor, indexed 
read, and printer port handler. Submitted 
by T. Wyant. 

1351.145] FINGER/RSX A kind of DECNET based 

WHO utility that shows who’s on the sys¬ 
tem. what they’re doing, and much more. 
Interfaces with the FINGER utility on 
VMS also, and permits displays across 
DECnet in either direction. Also acts as a 
name server (to find an account given a 
name) across the network. Submitted by 
Tom Wyant 

[351.146] Task Image Zapper. Gives formatted dump 

and ability to modify most task header 
fields (E.G. name, partition. LUN assign¬ 
ments, priority, creation date, commons, 
etc.)Calculator and radix converter. BRU 
command line builder. Submitted by Tom 
Wyant 

[352,4] SRD V6.62. Sorted Directory' and general 

file system maintenance utility. Now sup¬ 
ports either decimal or octal version num¬ 
bers. named directories. Selects these using 
the RSX FEATS directive, so it’ll work on 
most systems w/o taskbuild. Submitted by 
Arnold DeLarisch. 

[356.31] DATATRIEVE SIG items: information on 

reading quadword dates in FORTRAN. 
Process RSX console log files. Process RSX- 
11 M-PLUS system accounting with DTR. 
Graphing data on PRO-3.XX. 

[356.40] KERMIT. Several recent (1 14 88) KER- 

MITs are present, including KER.MIT-11, 
VMS KERMIT. MS. DOS KERMIT V2.30, 
CP/M KERMIT. C KERMIT. some IBM 
mainframe KERMITs. the new XKV ver¬ 
sion of C KERMIT. and a few document 
files and associated odds and ends. This is 
NOT a complete KERMIT distribution of 
all KERMITs, but each KERMIT presen¬ 
ted is complete(except for a few binaries of 
some machines and OSs which were re¬ 
moved to make some space). The full 
“KERMIT Distribution". DECUS Pro¬ 
gram No. V-SP-53. is available separately. 

Complete sources may or may not be included. 

Media (Service Charge Code): 2400' Magnetic Tape< PS) For¬ 
mat BRU. TK50 Tape Cartridge (TO Format BRU 


NEW UNIX PROGRAMS 

DECUS No: UX-SP-102 Title: UNISIG Collection Version: 
April 1987 

Submitted by™ Carl D. Lowenstein. Marine Physical Lab.. 
LaJolla, CA 

Operating System: ULTRIX-32 Vl.2. UNIX Source Language: 
C Keywords: Editors. Games, Text Formatting. Tools - Soft¬ 
ware Development, Utilities - VMS 

Abstract Following is a description of some of the highlights of 
the Spring 1987 UNISIG tape 

EDITORS Emacs V3.7, TVX (U. of A rizona), se 

(Georgia Tech). MicroEmacs. GNUEmacs. 
Macros to turn Emacs into EDT. 

GAMES Hack. larn. sniglet make phone numbers 

into words, rogomatic, game regulator. 
LANGUAGES Yacc and lex descriptions of ANSI C. 

FORTH. LISP. C preprocessors and cross- 
referencers, BASIC. 

DOCUMENTS C style manual, comparison of Berkeley 
and AT&T UNIX, compilation of uucp 
sites. 

TEXT 

PROCESSING Hershey fonts, TeX index maker. TeX syn¬ 
tax checker, drivers for LA50 and Laser¬ 
Jet printers, simple text formatters), ditroff 
to postscript 

TOOLS Software tools in PASCAL Turbo-PASCAL 

faster grep, file compression. 68K dis¬ 
assembler, remapping of long identifiers, 
automatic source patching, bundling and 
unbundling of files, string manipulation 
routines, getopt (3), suntools. btrees. 
COMPUTATION IEEE floating point routines, simplex curve 
fitting. 

COMMUNICATION News handling software, pathalias, zmodem, 
MSG mail system, remote procedure call. 
UTILITIES Rolodex, wire-wrap, ANSI tape read/write, 

calendars, collected useful shell scripts. 
BUGFIXES Published MtXinu fixes, collected Usenet 

4.2 BSD bugs. 

Media (Service Charge Code): 2400’ Magnetic Tape (PC) For¬ 
mat* UNIX/TAR, TK50 Tape Cartridge (TC) Format UNIX/ 
TAR 

NEW UNIX PROGRAMS 

DECUS No: UX-105 Title: SPICE3 Version: 3B.1. April 1987 

Submitted by: University of California at Berkeley, through 
Digital Equipment Corporation 

Operating System: ULTRIX/UNIX Source Language: C 
Memory Required: 65MB Software Required: VAX C Compiler 
Keywords: Circuit Simulation 

Abstract SPICE is a general-purpose circuit simulation pro¬ 
gram for nonlinear DC, nonlinear transient and linear AC ana¬ 
lysis. Circuits may contain resistors, capacitors, inductors, 
mutual inductors, ideal switches, independent voltage and 
current sources, four types of dependent sources, transmission 
lines and the five most common semiconductor devices; diodes. 
BJTs, JFETs, GaAs MESFETSs. and MOSFETS. 
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The ordering information for the manuals is as follows: 

• Order UX-105 (EA) for the User’s Guide 

• Order UX-105 (EB) for the User’s Manual 

• Order UX-105 (EC) for the Programmer's Manual 

Release notes are distributed with each order. 

Notes: Operating system UNIX V4.2 and V4.3BSD is required. 
This program was developed by the Computer-Aided Design 
Group, Department of Electrical Engineering and Computer 
Sciences, University of California-Berkeley. 

Restrictions: U.S. Government export regulations prohibit the 
distribution of this program outside the United States without 
the appropriate export licenses. 

Media (Service Charge Code): User's Manual (EA). User’s 
Manual (EB), User's Manual (EC). 2400’ Magnetic Tape (PA) 
Format: TAR 


DECUS No: UX-106 Title: RELAX2.3 Version: 2.3, March 
19S8 

Submitted by: University of California at Berkeley, through 
Digital Equipment Corporation 

Operating System: ULTRIX/UNIX Source Language: C 
Memory Required: 10MB Software Required: VAX C Compiler 
Keywords: Circuit Simulation 

Abstract: RELAX2.3 performs a fast and accurate transient 
analysis of Metal-Oxide-Semiconductor (MOS) integrated cir¬ 
cuits. The program uses a mixture of direct methods, like those 
used in the SPICE2 program, DECUS Program No. UX-109. 
and a modified version of the Waveform Relaxation (WR) algo¬ 
rithm. This combination of methods can greatly improve the 
computational efficiency of circuit simulation for MOS digital 
circuits by exploiting their loose coupling and relative inac¬ 
tivity. and can still efficiently solve tightly coupled analog cir¬ 
cuits by switching automatically to direct methods when 
appropriate. Using this combination of methods, RELAX2.3 
can produce results of the same accuracy as SPICE2 for both 
analog and digital MOS integrated circuits, but often uses less 
than ten percent of the computer time. 

The ordering information for the manuals is as follows: 

• Order UX-106 (EA) for the RELAX2.3 User’s Guide 

• Order UX-106 (ED) for the MULTIRATE INTEGRATION 
User’s Manual 

Release notes are distributed with each order. 

Notes: This program was developed by the Computer-Aided 
Design Group, Department of Electrical Engineering and Com¬ 
puter Sciences, University of California-Berkeley. 

Restrictions: U.S. Government export regulations prohibit the 
distribution of this program outside the United States without 
the appropriate export licenses. 

Media (Service Charge Code): User’s Manual (EA). User’s 
Manual (ED). 600’ Magnetic Tape (MA) Format: TAR 

DECUS No: UX-107 Title: MAHJONG Version: 1. October 
1986 

Submitted by: University of California at Berkeley, through 
Digital Equipment Corporation 


Operating System: ULTRIX/UNIX Source Language: C 
Memory Required: 789W Softw are Required: VAX C Compiler 
Keywords: Circuit Simulation 

Abstract: MAHJONG is a user-configurable test pattern gener¬ 
ation (TPG) system for combinational logic circuits. It takes as 
input a circuit file and performs a tailored TPG process specified 
by the user through various options. MAHJONG contains two 
front-ends, a deterministic TPG program, several heuristics for 
guided TPG. and a back-end. A parallel fault simulator is em¬ 
bedded in the deterministic TPG program as well as in the back¬ 
end and is not directly accessible to the users. 

The front-ends are heuristic TPG programs designed to efficien¬ 
tly generate test vectors for easily detectable faults. Users have 
the choice of the VICTOR-III front-end, the random front-end. 
or no front-end at all. Hard-to-detect faults are handled by the,, 
deterministic TPG program. Currently, this program is based 
on the PODEM algorithm. The back-end is a test compactor 
based on fault simulation and is very cost-effective. Fourguided 
TPG heuristics are currently provided for the PODEM-based 
deterministic program 

Notes: This program was developed by the Computer-Aided 
Design Group, Department of Electrical Engineering and Com¬ 
puter Sciences, University of Califomia-Berkeley. 

Restrictions: U.S. Government export regulations prohibit the 
distribution of this program outside the United States without 
the appropriate export licenses. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) For¬ 
mat: TAR 


DECUS No: UX-108 Title: GLITTER2 Version: 2. January 
1987 

Submitted by: University of California at Berkeley, through 
Digital Equipment Corporation 

Operating System: ULTRIX/UNIX Source Language: C 
Memory Required: 964W Software Required: VAX CCompiler 
Keywords: Circuit Simulation 

Abstract: GLITTER2 is a two-iayer channel routing and com¬ 
paction tool for the layout design of integrated circuits. It con¬ 
sists of the gridless channel router GLITTERand a newly-deve¬ 
loped channel spacer NUTCRACKER. The gridless approach 
we use can take advantage of different design rules on the two 
routing layers. No columns or tracks will be generated: only the 
wire width, spacing and contact size are considered. The major 
feature of this tool is to route channels with different wire 
widths and arbitrary terminal positions. It is also capable of 
handling channels with irregular boundaries. To minimize the 
channel height, contacts will be slid and necessary jogs will be 
automatically inserted. For channels with cyclic constraints, a 
preprocessor is used to generate the doglegs. The routing algo¬ 
rithm starts with a cycle-free weighted constraint graph, and 
generates a solution which minimizes the channel height 

Notes: Operating system UNIX V4.3BSD is required. This pro¬ 
gram was developed by the Computer-Aided Design Group, 
Department of Electrical Engineering and Computer Sciences. 
University of Califomia-Berkeley. 

Restrictions: U.S. Government export regulations prohibit the 
distribution of this program outside the United States without 
the appropriate export licenses. 


Media (Service Charge Code): User’s Manual (EA). 600' Mag¬ 
netic Tape(MA) Format: TAR 


DECUS No: UX-109 Title: SPICE2 Version: 2G.6. March 
1988 

Submitted by: University of California at Berkeley, through 
Digital Equipment Corporation 

Operating Sy stem: ULTRIX/UNIX Source Language: C. FOR¬ 
TRAN 77 Memory Required: 1.5MB Software Required: VAX 
C Compiler. FORTRAN 77 Compiler Keywords: Circuit Simu¬ 
lation 

Abstract: SPICE2 is a general-purpose circuit simulation pro¬ 
gram for nonlinear DC. nonlinear transient, and linear AC ana¬ 
lysis. Circuits may contain resistors, capacitors, inductors, 
mutual inductors, ideal switches, independent voltage and 
current sources, four types of dependent sources, transmission 
lines and the five most common semiconductor devices:diodes, 
BJTs, JFETs. GaAs MESFETSs. and MOSFETS. 

Release notes are distributed with each order. 

Notes: Operating system UNIX V4.1BSD is required. This pro¬ 
gram was developed by the Computer-Aided Design Group, 
Department of Electrical Engineering and Computer Sciences. 
University of Califomia-Berkeley. 

Restrictions: U.S. Government export regulations prohibit the 
distribution of this program outside the United States without 
the appropriate export licenses. 

Media (Service Charge Code): User’s Manual (EA), 600’ 
Magnetic Tape(MA) Format: TAR 


REVISIONS TO LIBRARY PROGRAMS 

DECUS No: VAX-238 Title: VMS Disassemblers PackageVer- 
sion: 3, March 1988 

Author Claus Calle, Andy Pavlin and others 

Operating System: MicroVMS. VAX 7 VMS Source Language: 
MACRO-32. VAX FORTRAN Keywords: Disassemblers 
Abstract Two VMS disassemblers capable of creating MACRO- 
32 sources from VMS native mode images are presented. All 
sources and brief documents are present, and one contains com¬ 
piled executable code so that it can be used by sites without 
FORTRAN. The disassembler so presented is capable of dis¬ 
assembling user mode images, drivers and other system images 
reasonably intelligently. All known areas where it was incom¬ 
plete have been squashed and the resulting.source code is VERY 
usable. Driver recognition and parsing has also been greatly 
upgraded, and all known RMS blocks are decoded. 

Notes: Executable code is present so no compiler is needed. 

Changes and Improvements: Understands VMS data struc¬ 
tures much better; all RMS blocks decoded. 

Media (Sendee Charge Code): 600’ Magnetic Tape (MA) For¬ 
mat VMS/BACKUP, or order VAX-LIB-7 
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SUBMITTING ARTICLES TO HARD NEWS 


The purpose of HARD NEWS, the HMS SIG newsletter, is to 
serve as a forum to share information related to DEC 
hardware with the members of the SIG. As such, the 
existence of the newsletter is entirely dependent on your 
contributions. If you have an HHK item, a better or safer 
way to do something, product news, a tutorial article of 
general interest, etc., we would like to publish it in the 
newsletter. We hope that HARD NEWS will be published at 
least six times a year. 

You can submit material to the editor, Carmen Wiseman, or to 
the HMS SIG chair. Bill Walker. We can accept submissions 
in a wide variety of formats: 

o Items can be sent to the editor on VMS-format RX50s, 
TK50 cartridges, or IBM PC format 5 1/4" floppies. The 
SIG chair prefers RT-11 floppies but can handle any 
reasonable media. 

o Hard copy, like cash, is always acceptable. 
Camera-ready copy will save us a lot of typing, but we 
don't insist on it. You can also use the Hardware 
Submission Form in the "Questionnaires" section of the 
combined SIGs Newsletters. 

o Those of you with access to DCS can send things to 
WALKER or WISEMAN. DCS is usually checked on a daily 
basis. 

o You can reach the SIG chair on CompuServe as 
"Bill Walker 71066,24" or via EasyLink mailbox 62752448 
or MCI Mail account 333-1675. You can reach the editor 
via EasyLink mailbox 62960090 (be sure to say ATTN: or 
TO: Carmen Wiseman somewhere in the body of the 

message) . 

If you have anything to submit, send it I If it is a mess, 
but we can read it, we will get it into the newsletter 
somehow. Finally, if you have any questions about 
submitting material, call one of us. The telephone numbers 
are listed below. 

Contributions can be sent to: 

William K. Walker Carmen D. Wiseman 

Monsanto Research Corp. OR Digital Review 

P.O. Box 32 A-152 == Prudential Tower, Suite 1390 

Miamisburg, OH 45342 800 Boylston Street 

(513) 865-3557 (work) Boston, MA 02199 

(513) 426-7094/0344 (home) (617) 375-4361 (work) 
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O DECUS U.S. CHAPTER 

SUBSCRIPTION SERVICE SIGS NEWSLETTERS ORDER FORM 

decus (U.S. Members Only) 


As a member of DECUS U.S. Chapter, you are entitled to contribute and subscribe to the DECUS monthly publication, 
SIGs Newsletters. You also have the opportunity to subscribe to the Symposia Proceedings which are a compilation 
of the reports from various speakers at the U.S. National DECUS Symposia. 

• No Purchase Orders will be accepted. 

• The order form below must be used as an invoice. 

• All checks must be made payable to DECUS. 

• All orders MUST be paid in full. 

• Minimum of $25.00 for orders placed via a credit card. 

• No refunds will be made. 

• The address provided below will be used for all DECUS mailings, i.e. Membership, Subscription Service and 

Symposia. 

• SIGs Newsletters Price is for a one-year subscription beginning the month following receipt of payment. 


Name_DECUS Member# 

Company_____ 

Address ____ 


City_State_Zip_ 

Telephone # ____ 


Subscription Service Offering 

SIGs Newsletters 
Fall’86 Proceedings(FA6) 
Spring’87 Proceedings (SP7) 
Fall’87 Proceedings (FA7) 
Spring ’88 Proceedings (SP8) 


Unit Price Quantity 

$35.00 _ 

15.00 _ 

15.00 _ 

15.00_ 

15.00 _ 


Total 


Total Amt. $ 


□ mastercard Dvisa Ddiners club/carte blanche® 

Credit Card #_____Expiration Date 

I understand that there will be no refunds even if I decide to cancel my subscription. 

Signature _______ 


FOR DIGITAL EMPLOYEES ONLY 

Badge #_________Cost Center___ 

Cost Center Mgr. Name_________Cost Center Mgr. Signature 

MAIL TO: Subscription Service, DECUS (BP02), 219 Boston Post Road, Marlboro, MA 01752-1850, (617) 480-3659. 


FOR DECUS OFFICE ONLY 

Check Number _ Bank Number 

Amount$ _ 


^ in _ o 










DECUS U.S. CHAPTER 
APPLICATION FOR MEMBERSHIP 


□ New Membership □ Update to current membership profile Current DECUS Member.#_ 

Please provide a complete mailing address, include zip code in accordance with postal regulations for your locality. 

Are you an employee of Digital Equipment Corporation? □ YES □ NO 


NOTE: Please print clearly or type! 

Name:_ 

(First) (Middle Initial) (Last/Family Name) 

Company:_ 

Address:_ 


I 


| City/Town/State/Zip: 

I 


! Telephone: Home( )_ Work( ) 

i 


S How Did You Learn About DECUS? Please Check Applicable Item. 

» 

■ 1 □ ANOTHER DECUS MEMBER 4D DIGITAL SALES 13 □ LOCAL USERS GROUP 

! 2 □ SYMPOSIA 5 □ HARDWARE PACKAGE 14D SPECIAL INTEREST GROUP 

£ 8 □ DECUS CHAPTER OFFICE 6D SOFTWARE PACKAGE 7D SOFTWARE DISPATCH (Digital Newsletter) 

■ 

• 10 □ DIGITAL STORE 12 □ ADVERTISING 

B 

a 

l 

to 

• . . . - . .—- 

t 

P 

s 

: 

• Do you wish to be included in mailings conducted by Digital (for marketing purposes eta?) □ Permission 

* □ Refusal 

J Type Of Digital Hardware Used: Please Check Those Applicable To You. 


20 □ 

DECMATE 


52 □ LSM1 


21 □ 

PROFESSIONAL 5D 

WPS-8 


82 □ 

DECSYSTEM-10 

3 □ PDP-8 FAMILY 

22 □ 

RAINBOW 

51 □ 

WPS-11 


83 □ 

DECSYSTEM-20 

50 □ PDP-11 

FAMILY 

54 □ 

VAX FAMILY 




1 

» Major Operating Systems? Languages Used: Please Check Those Applicable To You. 



lD 

ADA 

26 □ 

CORAL-66 

47 □ 

FOCAL 

67 □ 

OS/8 

109 □ 

RT-11 

! 2 O 

ALGOL 

28 □ 

COS 

48 □ 

FORTRAN 

68 □ 

PASCAL 

97 □ 

TECO 

5 □ 

■ 

APL 

34 □ 

DATATRIEVE 

51 □ 

GAMMA 

72 □ 

PL-11 

70 □ 

TOP&10 

7 □ 

BASIC 

35 □ 

DBMS 

110D 

IAS 

92 □ 

RPG 

71 □ 

TOPS-20 

■ 17 □ 

BLISS 

38 □ 

DECNET 

53 □ 

IQL 

81 □ 

RSTS/E 

111 □ 

ULTRIX/UNIX 

t 19 □ 

C 

43 □ 

DIBOL 

58 □ 

MACRO 

83 □ 

RSX 

104 □ 

VMS 

i 22 □ 

COBOL 

45 □ 

DOS-11 

65 □ 

MUMPS 

91 □ 

RMS 

107 □ 

WPS-8 
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Type Of Business(Environment)/Computer Applications 

Please Check That Which Best Describes Your Business/ Application. 


21 

□ 

ACCOUNTANCY 

i □ 

EDUCATION/PRIMARY 

23 □ 

NUMERICAL CONTROL 

7 

□ 

BANK 

2 □ 

EDUCATION/SECONDARY 

68 □ 

OEM-COMMERCIAL 

64 

□ 

BUSINESS/COMMERCIAL 

61 □ 

EDUCATION-TECHNOLOGY 

78 □ 

OEM-TECHNICAL 

74 

□ 

BUSINESS/INFORMATION SYSTEMS 

3 □ 

EDUCATION/U NIVERSITY 

56 □ 

PHYSICAL SCIENCES 

57 

□ 

CHEMISTRY 

67 □ 

ENGINEERING 

20 □ 

RESEARCH/DEVELOPMENT 

54 

□ 

CLINICAL LABORATORY 

65 □ 

FINANCE/ACCOUNTING 

10D 

RETAIL 

63 

□ 

COMPUTATION 

77 □ 

GOVERNMENT 

73 □ 

SOFTWARE DEVELOPMENT 

11 

□ 

CONSUMER ELECTRONICS 

75 □ 

GRAPHICS 

53 □ 

TELECOMMUNICATIONS 

18 

□ 

CONSULTANT 

4 □ 

HOSPITAL 

19 □ 

TELEPHONE/UTILITIES 

72 

□ 

DATA ACQUISITION 

62 □ 

INDUSTRIAL 

51 □ 

TIMESHARING 

52 

□ 

DATA COMMUNICATIONS 

55 □ 

LABORATORY/SCIENTIFIC 

80 □ 

TRAINING/INSTRUCTION 

13 

□ 

DATA PROCESSING SERVICES 

14D 

LIBRARY 

66 □ 

TYPESETTING/PUBLICATION 

71 

□ 

DATA REDUCTION 

58 □ 

LIFE SCIENCES 



17 

□ 

DIGITAL EMPLOYEE-ENGINEERING 

70 □ 

MANUFACTURING 



15 

□ 

DIGITAL EMPLOYEE-MARKETING 

79 □ 

MARKETING 



16 

□ 

DIGITAL EMPLOYEE-SERVICE GROUP 

59 □ 

MEDICAL RESEARCH 



60 

□ 

EDUCATIONAL ADMINISTRATION 

6 □ 

MILITARY INSTALLATION 




Special Interest Groups(SIGs) Enrollment 

I Wish To Participate In The Following DECUS U. S. Chapter Special Interest Groups. 


5 3 □ ARTIFICIAL INTELLIGENCE 

| 7 □ BUSINESS APPLICATIONS 

; 2 □ COMMERCIAL LANGUAGES 

{ 6 □ DATA MGMT. SYSTEMS 

S 31 □ DAARC(LABS) 

\ 5 □ DATATRIEVE/4GL 

S 8 □ EDUSIG 

• 10 □ GRAPHICS APPLICATIONS 


11 □ HARDWARE AND MICRO 
35 □ IAS 

27 □ LARGE SYSTEMS 
16 □ L& T 

14 □ MUMPS 

15 □ NETWORKS 

34 □ OFFICE AUTOMATION 


36 □ PERSONAL COMPUTER 

18 □ RSTS/E 
17 □ RSX 

19 □ RT-11 

32 □ SITE MGMT. & TRNG 
21 □ UNISIG 
26 □ VAX 


j Job Title/ Position - Please Check: 

; 1 □ CORPORATE STAFF 

■ 2 □ DIVISION OR DEPARTMENT STAFF 
; 3 □ SYSTEMS ANALYSIS 
! 4 □ APPLICATIONS PROGRAMMING 

• 5 □ SYSTEMS ANALYSIS/PROGRAMMING 

• 6 □ OPERATING SYSTEM PROGRAMMING 
t 7 □ DATABASE ADMINISTRATION 

{ 8 □ DATA COMMUNICATIONS/TELECOMMUNICATIONS 

? 9 □ COMPUTER OPERATIONS 

• 10D PRODUCTION CONTROL 


101 □ CORPORATE DIRECTOR OF DP/MIS 

102 □ ADMINISTRATIVE ASSISTANT 

103 □ TECHNICAL ASSISTANT 

104 □ SERVICES COORDINATOR 
105D MANAGER 

106D ANALYST 

107 □ PROGRAMMER 

108D DATABASE MANAGER 

109 □ DATABASE ADMINISTRATOR 

110D MANAGER OF DP OPERATIONS 


| Citizen of The United States of America? □ YES □ NO Country:___ 

■ 

S Signature:_Date:. 

J Forward To: DECUS U. S Chapter 
| Digital Equipment Computer Users Society 

• Membership Processing Group 

S 219 Boston Post Road, BP02 

; Marlboro MA 01752-1850 

S Phone (617)480-3418 

! DTN: 8-296-3418 
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STEERING COMMITTEE LISTS 



ARTIFICIAL INTELLIGENCE SIG 

CHAIR 

Cheryl Jalbert 
JCC 

128 West Broadway 
Granville, OH 43023 

(614) 587-0157 

VICE-CHAIR 

OPS5 WORKING GROUP CHAIR 

Don Rosenthal 
Space Telescope Science Inst 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

NEWSLETTER TASK FORCE CHAIR 
ADMINISTRATIVE ASSISTANCE 

Becky Wise 
Amdalh CSD 

2200 North Greenville Ave. 

Richardson, TX 75081 
(214) 699-9500 x 272 
NEWSLETTER EDITOR 
Terry Shannon 
Computer Info. Sys., Inc. 

Technical Consultant 
165 Bay State Drive 
Braintree, MA 02184 
(617) 848-7515 

SYMPOSIA COORDINATOR 

Pam Vavra 

Hughes Aircraft EDSG 
P.O. Box 902 E52/D220 
El Segundo, CA 90245-0902 
(213) 616-7071 

MEMBERSHIP COORDINATOR 
SUITE COORDINATOR 

Chris Goddard 
Simpact Associates 
9210 Skypark Court 
San Diego, CA 92123 
(619) 565-1865 

SESSION NOTE EDITOR 
George Humfeld 
Naval Sea Systems Command 
PMS 350 ED Dept of the Navy 
Washington, DC 20362-5101 
(202) 692-0137 

ASS’T SESSION NOTES EDITOR 
David Frydenlund 
STORE REPRESENTATIVE 
Sally Townsend 
Inst. Defense Analysis 
1801 N. Beauregard St 
Alexandria, VA 22311 
(703) 845-2122 

PUBLIC DOMAIN SOFTWARE TF CHAIR 
LIBRARY REPRESENTATIVE 

Jim Sims 

Space Telescope Science Ins. 

3700 San Martin Drive 
Baltimore, MD 21218 
(301) 338-4949 

AI LUG COORDINATOR 
ASSISTANT STORE REP. 

Dennis Clark 
RT2 Box 264 
Kingston, TN 37763 

(615) 576-7384 

REPORTER TO THE UPDATE.DAILY 
Bill Lennon 


SEMINAR UNIT REP. 
CAMPGROUND COORDINATOR 

Leona Fluck 

Educational Testing Service 
Rosedale Road 
Princeton, NJ 08540 
(609) 734-1243 
DEC COUNTERPART 
Art Beane 
Hudson, MA 

MEMBERS-AT-LARGE 
David Slater 
George Winkler 
Jeff Fox 

John Williamson 

Wayne Graves 

Matt Mathews 

Dave Campbell 

Shirley Bockstahler-Brandt 

Barry Breen 

Tom Viana 



BUSINESS APPLICATIONS SIG 

CHAIRMAN 

George Dyer 
Gallaudet University 
800 Florida Ave, NE-EMG Bldg 
Washington, DC 20002 
(202) 651-5300 

COMMUNICATIONS COORDINATOR 

Steve Lacativa 
Price Waterhouse 
153 East 53rd Street 
New York, NY 10022 
(212) 371-2000 x 3107 
SYMPOSIA COORDINATOR 
Mark Hults 

USSA Administrative Systems 
USSA Bldg. B01E 
San Antonio, TX 78288 
(512) 498-8725 
LUG COORDINATOR 
Patrick LeSesne 
U.S. Coast Guard 
Room 1416E 2100 2nd St SW 
Washington, DC 20593 
(202) 267-0354 

MARKETING COORDINATOR 

Tom Byrne 
L Karp & Sons 
1301 Estes 

Elk Grove Village, IL 60007 
(312) 593-5706 

PROGRAM PLANNING COORDINATOR 

Stuart Lewis 
Douglas Furniture Corp. 

P.O. Box 97 

Bedford Park, IL 60499 
(312) 458-1505 

SEMINARS COORDINATOR 

Daniel Esbensen 
Touch Technologies, Inc. 

9990 Mesa Rm , Rd. #220 
San Diego, CA 92121 
(619) 455-7404 
LRP COORDINATOR 
Arnold I. Epstein 
D-M Computer Consultants 
Rolling Meadows, IL 60008 
(312) 394-8889 


NEWSLETTER EDITOR 

Dave Levenberg 
Credit Suisse 
Dept OA1 15th floor 
100 Wall Street 
New York, NY 10005 
(212) 612-8372 

SESSION NOTE EDITOR 

Marty Schmitt 
Harris Publishing 
3 Barker Avenue 
White Plains, NY 10601 
(914) 946-7500 x 287 
LIBRARY REPRESENTATIVE 
David Hittner 
Projects Unlimited 
3680 Wyse Road 
Dayton, OH 45414 
(513) 890-1800 
CL SIG LIAISON 

Becky Burkes-Ham 

DMS SIG LIAISON Joe Sciuto MEMBERS-AT-LARGE 
Robert D. Lazenby 
Dixie Beer Dist, Inc. 

Louisville, KY 
Robert Kayne 
Gallaudet College 
Washington, DC 
Ray Evanson 
Paragon Data Systems 
Winona, MN 

DEC COUNTERPARTS 

Sue Yarger 

Digital Equipment Corporation 
Merrimack, NH 03054-0430 
Paula Daley 

Digital Equipment Corporation 
Merrimack, NH 03054-0430 
Pam Kukla 

Digital Equipment Corporation 
Maynard, MA 01754 


Wombat Magic 



DATATRIEVE/4GL SIG 

CHAIRMAN 

Joe H. Gallagher 
Research Medical Center 
2316 East Meyer Blvd 
Kansas City, MO 64132 
(816) 276-4235 

SYMPOSIA COORDINATOR 

Lisa M. Pratt 
Vitro Corporation 
Nuwes Code 3144 
Keyport, WA 98345 
(206) 396-2501 

ASS‘T SYMPOSIA REPRESENTATIVES 
T.C. Wool 

E.I. duPont DeNemours & Co. 
Engineering Dept. 

P.O. BOX 6090. 

Newark, DE 19714-6090 
Janet G. Banks 
Weyerhaeuser Info. Sys. 

Mail Stop CCB-2E 
Tacoma, WA 98477 
(206) 924-4082 
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COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Donald E. Stem, Jr. 

Warner Lambert Company 
10 Webster Road 
Milford, CT 06460 
(203) 783-0238 

ASSOCIATE NEWSLETTER EDITOR 

Steve Cordiviola 
Kentucky Geological Survey 
311 Breckinridge Hall 
Lexington, KY 40506 

(606) 257-5863 
Pasquale (Pat) F. Scopelliti 
Coming Glass Works 
Mail Stop MP-RO-01-1 
Coming, New York 14831 

(607) 974-4496 
Lorey B. Kimmel 
Thomson-CGR Medical Corp. 

10150 Old Columbia Road 
Columbia, Maryland 21046 
(301) 290-8757 

Herbert G. Reines 
Reznick Feddder & Silverman 
4520 East West Highway 
Suite 300 

Bethesda, MD 20814 
(301) 652-9100 
Alan Winston 

Stanford Synchrotron Radiation Lab. 
SLAL BIN 69 
P.O. Box 4349 
Stanford, CA 94305 
(415) 854-3300 x2874 
VOLUNTEER COORDINATOR 
Susan Krentz 
NKF Engineering 
12200 Sunrise Valey Dr. 

Reston, VA 22091 
(703) 620-0900 

ASSISTANT VOLUNTEER COORD. 

Harry Miller 
City of Ontario Police 
200 N. Cherry Avenue 
Ontario, CA 91764 
(714) 988-6481 
SEMINARS 

Dana Schwartz 
15719 Millbrook Lane 
Laurel, MD 20707 
(301) 859-6277 

SESSION NOTES EDITOR 

Bernadette Reynolds 
City of Ontario Police 
200 N. Cherry Avenue 
Ontario, CA 91764 
(714) 988-6481 
CAMPGROUND 

Bert Roseberry 
Commandant (G-APA-1) 

2100 2nd Street, S.W. 

Washington, DC 20593-0001 
(202) 267-2629 
WW EDITOR 
PIR COORDINATOR 

Philip A. Naecker 
Consulting Engineer 
3011 N. Mount Curve Ave. 

Altadena, CA 91001 
(818) 791-0945 
DEC COUNTERPARTS 
DATATRIEVE 

Mary Ann Fitzhugh 
110 Spit Brook Road 
ZK2-2/M28 
Nashua, NH 03060 
(603) 881-2329 

ARTIST & LIBRARY REP. 

Bart Z. Lederman 

I.T.T. World Communications 

67 Broad Street (28th Floor) 

New York, NY 10004 
(212) 607-2657 


RALLY WORKING GROUP CHAIR 

Steven G. Fredrickson 
Fredrickson Consulting Service 
107 1st Avenue N. 

Seattle, WA 98109 
(206)283-0273 

POWERHOUSE W/G CHAIR 

David Nagumey 
TSO Financial Corp. 

Five TSO Financial Center 
Three Hundred Welsh Road 
Horsham, PA 19044-2009 
(215) 657-4000 

DMS&CLSIG LIAISON 
William Tabor 
W.I. Tabor, Inc. 

12018 Royal Palm Blvd. 

Coral Springs, FL 33065 
(305) 755-7895 

SMARTSTAR WORKING GROUP CHAIR 

Thomas Colati 
Time Enterprises 
301 North Harrison 
Suite 101 

Princeton, NJ 08540 
(800) 548-6865 

ACCENT-R USER GROUP LIAISON 
Winston Tellis 
Fairfield University, 

North Benson Road 
Fairfield, CT 06430 
(203) 255-5411 

ORACLE WORKING GROUP CHAIR 
Eric S. Fanwick 
Xerox Corp. 

P.O. Box 1600 
Stamford, CT 06904 
(203) 329-8700 

FOCUS WORKING GROUP CHAIR 
Les Hulse 

The Gillette Company 
Prudential Tower Bldg. 

Boston, MA 02199 
(617) 421-7910 



DAARC SIG 

CHAIRMAN 

James Deck 

Inland Steel Research Lab. 

3001 East Columbus Drive 
East Chicago, IL 46312 
(219) 392-5613 

SYMPOSIA COORDINATOR 

Mack Overton 
FDA 

Chicago, IL 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Dale Hutchison 
Cummins Engine Co. 

4720 Baker St., Ext. 

Lakewood, NY 14750 
(716) 456-2191 
DEC COUNTERPART 
Bill Forbes 
Marlboro, MA 


HARDWARE & INTERFACING 

Peter Clout 

Los Alamos National Lab 
Los Alamos, NM 

MATH STATISTICS & ANALYSIS 
Herbert J. Gould 
C.C.F.A. Univ. of Ill. Medical Ctr. 

Chicago, IL 

PROCESS CONTROL-INDUSTRIAL AUTOMATION 

Bill Tippie 

Kinetic Systems Corp. 

Lockport, IL 

RS-1 

George Winkler 
CPC International 
Argo, IL 



DATA MANAGEMENT SYSTEMS SIG 

CHAIRMAN 

Doug Dickey 

GTE Government Systems 
1700 Research Blvd. 

Rockville, MD 20850 
(301) 294-8462 
MEMBER AT LARGE 
Alan Schultz 

Southwestern Bell Yellow Pages 
12800 Publication Dr., Suite 108 
St Louis, MO 63131 
(314) 957-2029 

SYMPOSIA COORDINATOR 
SQL Standards Rep. 

Keith Hare 
JCC 

P.O. Box 463 
Granville, OH 43023 
(614) 587-0157 

COMMUNICATIONS REP. 

Debbie Kennedy Coleman 
Shane Co. 

2 W Washington St., Suite 600 
Indianapolis, IN 46204 
(317) 635-9100 
NEWSLETTER EDITOR 
William Packard 
Mass Mutual Life Ins. 

1296 State Street B-391 
Springfield, MA )1111 
(413) 788-8411 

SESSION NOTE EDITOR 
Mark Morgan 
Farm Credit Banks 
P.O. Box 141 
Springfield, MA 01102 
(413) 786-7600 

MEMBERSHIP COORDINATOR 
MEMBER AT LARGE 
Rocky Hayden 
Userware International 
2235 Meyer Avenue 
Escondido, CA 
(619) 745-6006 
MEMBER AT LARGE 
PAST SIG CHAIRMAN 
Steve Pacheco 
Ship Analytics 
North Stonington, CT 06359 
(203) 535-3092 
PAST SIG CHAIR 
MEMBER AT LARGE 
Joe Sciuto 
U.S. Army 

5910 Westchester Street 
Alexandria, VA 22310 
(202) 692-6903 
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SEMINAR REP. 

Stephen Gomez 
Signal Technology 
1700 Montgomery St. 

San Francisco, CA 94111 
(415) 954-8532 

WORKING GROUP COORDINATOR/ 

Jim Perkins 
PSC, Inc. 

20 Kimball Ave., Suite 305 
Shelburne, VT 05401 
(802) 863-8825 

CAMPGROUND COORDINATOR 

Rosemary O’Mahony 
Arthur Anderson & co. 

33 West Monroe Street 
Chicago, IL 60603 
(312) 507-6510 

SESSION CHAIR COORDINATOR 

Andy Menezes 
AD & E 

29-B Montvale Avenue 
Woburn, MA 01801 
(617) 938-1979 

Rdb WORKING GROUP Coordinator 

Howard Cheng 

Bechtel Western Power Corp. 

12440 East Imperial Highway 
Norwalk, CA 90650 
(213) 807-4077 

ROADMAP COORDINATOR 

Elizabeth Irving 

Dupont 

P.O. Box 1089 

Orange, Texas 77630-1089 

(409) 886-9427 

DBMS COORDINATORS 

Bryan Holland 
1006 Pleasant St., #20 
Weymouth, MA 02189 
(617) 335-7573 
Paul E. Reese 
Aetna, Systems Dept 
Financial Division 
CityPlace 

Hartford, Connecticut 06156 
(203) 275-2012 
MEMBER AT LARGE 
Jim Redfield 
BDM 

9020 N. Cap. of Texas Highway 
Austin, TX 78759 
(512) 346-6760 

STORE REPRESENTATIVE 
FIMS STANDARDS REP. 

Paul W. Plum, Jr 
Lukens Steel Company 
Coatesville, PA 19320 
(215) 383-2024 

RMS WORKING GROUP COORDINATOR 

Allen Jay Bennett 
Logisticon, Inc. 

5035 Whitneyville Road 
Ada, MI 49301 
(616) 452-1823 
DEC COUNTERPART 
Wendy Herman 
John Wood 
Nashua, NH 



EDUSIG 

CHAIRMAN 

Robert A.Shive, Jr. 
Millsaps College 
Jackson, MS 39210 
(601) 354-5201 


SYMPOSIA COORDINATOR 

Mary Jac Reed 
Off Comp Based Instruction 
University of Delaware 
305 Willard Hall 
Newark, DE 19716 
(302) 451-8161 

COMMUNICATIONS REPRESENTATIVE 

Robert W. McCarley 
Millsaps College 
Jackson, MS 39210 
(601) 354-5201 
NEWSLETTER EDITOR 
Fred Bell 
Taft College 
29 Emmons Park Drive 
P.O. Box 1437 
Taft, CA 93267 
(805) 763-4282 
PSS COORDINATOR 
VAX SYSTEMS SIG LIAISON 
Donald C. Fuhr 
Tuskegee Institute 
Tuskegee Institute, AL 36088 
(205) 727-8242 

ADMINSTRATIVE APPLICATIONS COORD. 

Dave Cothrun 
Taft College 
29 Emmons Pk Drive 
P.O. Box 1437 
Taft, CA 93268 
(805) 763-4282 

SESSION NOTE EDITOR 

Paula Barnes 
Guilford College 
5800 West Friendly Avenue 
Greensboro, NC 17410 
(919) 292-5511 
DEC COUNTERPART 
Gary Finerty 
Marlboro, MA 



DECUS 


Graphics 

Applications 


GRAPHICS APPLICATIONS SIG 

CHAIRMAN 

Bijoy Misra 

Smithsonian Institution 
60 Gordon St., MS39 
Cambridge, MA 02138 
(617) 495-7392 

SESSION NOTE EDITOR 

Carol Schwob 
Florida Atlantic Univ. 

Bldg. 22, Room 106 
Boca Raton, FL 33431 
(305) 393-2640 

NEWSLETTER EDITOR (acting) 

OPEN 

ASSOCIATE NEWSLETTER EDITOR 

Charles D. Carter 
Huntington Alloys, Inc. 

Technology Dept. 

P.O. Box 1958 
Huntington, WV 25720 
(304) 526-5721 

WORKSTATION WORKING GROUP COORD. 

Bob McCormick 

Video Communications, Inc. 

1325 Springfield Street 
Feeding Hills, MA 01030 
(413) 786-7955 

ENGINEERING GRAPHICS WORKING GROUP COORD. 

Eric Rehm 
Gonzaga University 
SPOCAD 
E 502 Boone 
Spokane, WA 99258 
(509) 484-6814 


COMMUNICATIONS REP 
NEWSLETTER EDITOR 

Robert Hays 
KMS Fusion 
3621 So. State Road 
Box 1567 

Ann Arbor, MI 48106 
LIBRARY COORDINATOR 
Mike McPherson 
Michigan University 
269 Engineering Bldg. 

East Lansing, MI 48824 
(517) 353-9769 

STANDARDS COORDINATOR 

OPEN 

VOLUNTEER COORDINATOR 
Dick McCurdy 
University of Florida 
Room 216, Larsen Hall 
Gainsville, FL 32611 
(904) 392-4915 
LIBRARY COMMITTEE 
James M. Turner 
Saber Technology 
San Jose, CA 
DEC COUNTERPART 
Jim Flatten 
Spit Brook, NH 
Rick Landau 
Marlboro, MA 

INFORMATION OFFICER 

Mike York 

Boeing Computer Services 
P.O. Box 24346 M/S 03-73 
Seattle, WA 98124 
(206) 342-1442 

SYMPOSIUM COORDINATOR 

Dottie Elliott 
Northrop Services Inc. 

P.O. Box 12313 

Research Triangle PK, NC 27709 
(919) 541-1300 

DATA DISPLAY WORKING GROUP COORD. 
Joy Williams 
Eaton Corp. 

P.O. Box 766 
Southfield, MI 48037 

HARD 

NEWS 

HARDWARE MICRO SIG 

CHAIRMAN 

Willian K. Walker 
Monsanto Research Corp. 

Miamisburg, OH 

PRODUCT PLANNING COORDINATOR 

George Hamma 
Synergistic Technology 
Cupertino, CA 

PRE-SYMPOSIUM SEMINAR COORDINATOR 

James R. Lindesmith 
Monsanto Research Corp. 

Miamisburg, OH 

COMMUNICATIONS COORDINATOR 

John G. Hayes 
Information Systems 
South Central Bell 
Birmingham, AL 
NEWSLETTER EDITOR 

Carmen D. Wiseman 
Digital Review 
Boston, MA 

SESSION NOTE EDITOR 
DAARC SIG LIAISON 

Bill Tippie 

Kinetic Systems Corp. 

Lockport, IL 
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STANDARDS COORDINATOR 

CAMAC WORKING GROUP COORDINATOR 

Peter Clout 

Los Alamos National Lab 
los Alamos, NM 
LUG COORDINATOR 
Gregg Giesler 
Los Alamos Science Lab 
Los Alamos, NM 
TOEM (CHIPS & BOARDS) 

Jack J. Peterson 
Horizon Data Systems 
Richmond, VA 

HHK (HARDWARE HINTS & KINKS) 

Wayne Kesling 
Monsanto Research Cor. 

Miamisburg. OH 
UNIBUS HARDWARE 
Ron Bogue 

LIV Aerospace & Defense Co. 

Dallas, TX 

PERFORMANCE MEASUREMENT COORD. 
William Wallace 
600 W. Washington Street 
Peoria, IL 

CSS COORDINATOR 
Pratap Gohel 
E.I. duPont 
Ingleside, TX 

NETWORKS SIG LIAISON 
Sandra Traylor 
Target Systems 
Yorba Linda, CA 
VAX SIG LIAISON 
Dave Schmidt 
5100 Centre Avenue 
Pittsburgh, PA 
UNISIG LIAISON 

Jim Livingston 
1 Results Way 
Cupertino, CA 
SITE SIG LIAISON 
Emily Kitchen 
A.H. Robins Co. 

Richmond, VA 
RT-11 SIG LIAISON 
Gary Sallee 

Sallee Software Consulting 
yorba Linda, CA 
RSX SIG LIAISON 
Hans Jung 
Associated Press 
New York, NY 
MEMBERS-AT-LARGE 
Mike Rembis 
American Dade 
Costa Mesa, CA 
Hans Dahlke 
Richland, WA 
Jim Cutler 
EDS Tower 
16533 Evergreen 
Southfield, MI 

DEC COUNTERPARTS TERMINALS 
Nina Abramson 
Maynard, MA 
TOEM (Chips & Boards) 

Art Bigler 
Marlboro, MA 
DIAGNOSTIC 

George D. Cooke 
Maynard, MA 
STORAGE 

Marilyn Fedele 
Maynard, MA 

MSD (Micro Systems Develp.) 

Roy Rodgers 
Maynard, MA 
PRINTER PRODUCTS 
Frank Orlando 
Maynard, MA 

DECUS EUROPE LIAISON 
Hans Zoller 



IAS SIG 
CHAIRMAN 

Alan Frisbie 

Flying Disk Systems, Inc. 

4759 Round Top Drive 
Los Angeles, CA 90065 
(213) 256-2575 
NEWSLETTER EDITOR 
Frank R. Borger 
Radiation Therapy 
Michael Reese Medical Center 
Lake Shore Drive @ 31st St 
Chicago, IL 60616 
(312) 791-2515 

WHIMS COORDINATOR 

Kathleen Anderson 
Eaton Information Management 
System Division 
Hampton, VA 
(804) 326-1941 
RSX LIAISON 

Ray French 

Boeing Computer Services 
Seattle, WA 
(206) 655-6228 
MEMBER-AT-LARGE 
Doug Reno 
Abbot Laboratories 
North Chicago, IL 
(312) 937-7504 
PAST CHAIRMAN 

Mike Robitaille 
Grumman - CTEC, Inc. 

6862 Elm Street 
McLean VA 22101 
(703) 556-7400 x431 
CHAIRMAN EMERITUS 
Bob Curley 

Division of Medical Physics 
University of Pennsylvania 
Philadelphia, PA 
(215) 662-3083 

SYMPOSIA COORDINATOR 
Lynda L. Roenicke 
Special Systems Branch 
Naval Ocean Systems Center 
271 Cataline Blvd Code 742 
San Diego, CA 
(619) 225-7569 

LIBRARY COORDINATOR 

Ted Smith 

The University of PA 
Philadelphia, PA 19101 
(215) 662-3500 
MEMBER-AT-LARGE 
Kerry Wyckoff 
Salt Lake City, UT 
DEC COUNTERPART 

Nancyfaye Autenzio 
Stow, MA 
(617) 496-9606 


Leverage 


^ages yr 


LANGUAGES AND TOOLS SIG 

CHAIRMAN 

Sam Whidden 

American Mathematical Society 
201 Charles St 
P.O. Box 6248 
Providence, RI 02940 
(401) 272-9500 
VICE CHAIR 

SYMPOSIA COORDINATOR 

Earl Cory 
Eaton Corporation 
31717 La Tienda Dr. 

Westlake Village, CA 91359 
(818) 706-5385 

STORE REPRESENTATIVE 
Chair, TECH. PROD OF DOC. W/G 

Howard Holcombe 
RCA 

Front & Cooper Sts. 

Camden, NJ 08055 
(609) 338-4946 
NEWSLETTER EDITOR 
ALT. CommComm REP. 

A1 Folsom, Jr. 

Fischer & Porter Co. 

E. County Line Rd. 

Warminster, PA 18974 
(215) 674-7154 

SESSION NOTES EDITOR 

Mark Katz 

GTE Government Systems 
100 First Avenue 
Waltham, MA 02154 
(617) 466-3437 

AUSTRALIAN L&T INTERFACE 

Gordon Brimble 
Bldg. 180 Labs Area 
Defence Research Centre 
Box 2151 GPO 

Adelaide, S.A. Australia 5001 
(61)(8)259-6119 

INTERSIG COORDINATOR 

Dorothy Geiger 
Wollongong Logistics Group 
49 Showers Drive #451 
Mountain View, CA 94040 
(415) 948-1003 
(415) 962-7160 
EUROPEAN METHODS 
L&TINTERFACE 
Bernd Gliss 
Max-Planck-Institute 
Heisenbergstra Be 1 
7000 Stuttgart 80, W. Germany 
(711) 686-0251 
PAST CHAIR 

PRODUCTIVITY TOOLS COORDINATOR 

Kathy Hornbach 
Digital Equipment Corporation 
110 Spit Brook Rd., ZK03-3/Y25 
Nashua, NH 03062 
(603) 881-2505 

CHAIR TECO WORKING GROUP 

Mark J. Hyde 

Advanced Computing Services 
209 Ardsley Drive 
DeWitt, NY 13214 
(315) 446-7223 

MEMBER, ANSI BASIC X3J2 STDS, COMM. 
STANDARDS COORD. 

PDP-11 REP. 

CHAIR, PDP-11 LAYERED PRODUCT W/G 

Stephen C. Jackson 
SCJ Consulting, Inc. 

7260 University Avenue N.E. 

Suite 105 

Minneapolis, MN 55432 
(612) 571-8430 
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CHAIR, CONFIG. MGMT. WORKING GROUP 

Mark Alan Kidwell 
Texas Instruments Inc. 

P.0. Box 869305 M/S 8435 
Plano, TX 75086 
(214) 575-3547 

DEVEL. COUNTERPART, PDP-11 SOFTWARE 

Joe Mulvey 

Digital Equipment Corp. .ZK01-3/J10 
110 Spit Brook Road 
Nashua, NH 03062-2642 
(603) 881-1218 

LISP/AI COORDINATOR 

Don Rosenthal 

Space Telescope Science Institute 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

LIBRARY REPRESENTATIVE 

SIGTAPE LIBRARIAN 

CHAIR, PUBLIC DOMAIN SOFTWARE W/G 

Tony Scandora 

Argonne National Laboratory 

GMT 205 

Argonne, IL 60439 
(312) 972-7541 

CHAIR, C WORKING GROUP 

James Maves 
Eaton Corp, IMSI) 

31717 La Tienda Drive 
Box 5009 

Westlake Village. CA 91359 
(818) 706-5395 
COMMCOMM REP. 

Jay Wiley 

Bechtel Power Corp 

12400 East Imperial Highway 

Norwalk, CA 90650 

(213) 807-4016 

SESSION CHAIRS COORDINATOR 
BOF CHAIRS COORDINATOR 
SESSIONS QUALITY COORD. 

ALT. SYMPOSIUM COORD. 

Gary C. Lelvis 
IMSL 

2500 Park West Tower One 
2500 City West Blvd. 

Houston, TX 77042-3020 
(713) 782-6060 

CHAIR, FORTRAN WORKING GROUP 

Scott Krusemark 

8473 Daisywood Ave N.W. 

North Canton, OH 44720 
(216) 499-6251 

CHAIR, LOW LEVEL LANGUAGES W/G 

Gerald Lester 

Computerized Processes Unlim. 

2901 Houma Blvd. Suite 5 
Metairie, LA 70006 
(504) 889-2784 

DEVEL. COUNTERPART, COMM. LANG. 

Jim Totton 

Digital Equipment Corp. 

ZK02-3/K06 

110 Spit Brook Road 

Nashua, NH 03062 

ALT. ANSI X3J9 PASCAL STDS. COMM. 

Phil Wirth 

E-Systems, Garland Division 
Box 660023, MS 53730 
Dallas, TX 75266-0023 

(214) 272-0515 x4319 

ALT. ANSI X3J4 COBOL STDS. COMM. 

Dale Marriott 

El Paso County Office Bldg. 

27 E. Vermijo Street 
Colorado Springs, CO 80903 
(303) 520-6435 

CHAIR, DIBOL WORKING GROUP 

ASSOC, W/G COORD. UNSCHEDULED TOPICS 

ACTING CHAIR, COBOL WORKING GROUP 

Bruce Mebust 

Burlington Northern Railroad 
176 East Fifth Street 
P.O. Box 64962 
St. Paul, MN 55164 
(612) 298-2382 


CHAIR, SECURITY WORKING GROUP 

Rich Harris 

General Research Corp. 

5383 Hollister Avenue 
P.O. Box 6770 

Santa Barbara, CA 93160-6770 
(805) 964-7724 

ASSISTANT CAMPGROUND COORD. 

Tom J. Jeffrey 

Rockwell International Corp. 

1225 N. Alma Road 
Richardson, Texas 75081 
(214) 996-7818 

CHAIR, ADA WORKING GROUP 

Lisa Kerby- Rodgers 
GTE Government Systems 
100 Ferguson Drive 
P.O. Box 7188 
Mountain View, CA 94039 
(415) 966-2720 

CHAIR, PROJECT MANAGEMENT W/G 

Lynn C. Lewis 

Lawrence Livermore National Lab. 
University of California 
P.O. Box 808 
Livermore, CA 94550 
(415) 422-8949 

TEMP. CHAIR, OBJ. ORIENTED DES. W/G 

Frank B. Modruson 
Arthur Andersen & Co. 

33 West Monroe Street 
Chicago, IL 60603 
(312) 580-0033 

CHAIR, TeX/LaTEX WEB W/G 
John Osudar 
Argonne National Lab. 

9700 South Cass Avenue 
Argonne, IL 60439 
(312) 972-7505 
CHAIR, VAXset W/G 
David J. Powell 
The Upjohn Company 
7263-267-712 
301 Henrietta St 
Kalamazoo, MI 49007 
(616) 344-3341 

MEM., ANSI DIBOL X3J12 Stds. Comm. 
Kenneth Schilling 
2314 Mira Vista Avenue 
Montrose, CA 91020 
(818) 249-0795 

SUITE & RECEPTION COORD. 

Matt Variot 
Eaton Corporation 
Box 5009 

31717 La Tienda Drive 
Westlake Village, CA 91359 
(818) 706-5388 

CHAIR, TPU/EVE/LSE W/G 
John Wilson 
Aetna Life & Casualty 
City Place YFB3 
Hartford, CT 06103 
(203) 275-2064 
VICE CHAIR 

SYMPOSIUM LOGISTICS COORD. 

Terry Medlin 
Survey Sampling, Inc. 

1 Post Road 
Fairfield CT 06432 
(203) 255-4200 

MASTERS COORDINATOR 

Dena Shelton 
Cullinet Software Inc. 

2860 Zanker Rd, Suite 206 
San Jose, CA 95134 
(408) 434-6636 

ACTING CHAIR, APL WORKING GROUP 
CHAIR, BASIC W/G 
WISHLIST COORDINATOR 

Bob Van Keuren 
UserWare International, Inc. 

2235 Meyers Ave. 

Escondido, CA 92025 
(619) 745-6006 


WORKING GROUPS COORD. 
CAMPGROUND COORDINATOR 

Joseph Pollizzi, III 
Space Telescope Science Institute 
3700 San Martin Drive 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4901 

CHAIR, SCAN WORKING GROUP 
CHAIR, PL/1 WORKING GROUP 
VOLUNTEERS COORD. 

David Ream 
Lexi-Comp 

26173 Tallwood Drive 
N. Olmsted, OH 44070 
(216) 777-0095 
(216) 468-0744 

CHAIR, PASCAL WORKING GROUP 
MEMBER, ANSI PASCAL X3J9 STDS. COMM. 
CHAIR, MODULA-2 W/G 

E. Wayne Sewell 
E-Systems, Garland Div. 

Box 660023, MS 53700 
Dallas, TX 75266-0023 
(214) 272-0515 x3553 

CHAIR, SOFTWARE METRICS W/G 

Michael S. Terrazas 
LDS Church 

50 E. North Temple, 27th Floor 
Salt Lake City, UT 84150 
(801) 531-3246 

MEMBER, ANSI COBOL X3J4, STDS, COMM. 

Bruce Gaarder 
Donahue Enterprises, Inc. 

2441 26th Ave., S. 

Minneapolis, MN 55406 
(612) 721-2418 

ALT. SEMINAR COMM REP. 

Janet E. Bressan 
Boeing Aerospace Co. 

P.O. Box 3999, MS3C-24 
Seattle, WA 98124 
(206) 773-9404 

CHAIR, RPG WORKING GROUP 

Charles Williamson 
Hargray Telephone Co. 

P.O. Box 5519 

Hilton Head Is., SC 29938 

(803) 686-1204 

SEMINAR COMMITTEE REP. 

Barry C. Breen 

Sundstrand Data Control, Inc. 

15001 N.E. 36th Street 
P.O. Box 97001 
Redmond, WA 98073-9701 
(206) 885-8436 

ASSIST. MASTERS COORD. 

CLINIC DIRECTOR 

CHAIR, CASE & TOOLS INTEGRATION W/G 

George Scott 
Computer Sciences Corp. 

304 West Route #38, P.O. Box N 
Moorestown, NJ 08057 
(609) 234-1100 

ASSISTANT CAMPGROUND COORD. 

Keith Batzel 
Crowe, Chizek & Co. 

330 E. Jefferson 
Box 7 

South Bend, IN 46624 
(219) 232-3992 

DEVEL. COUNTERPART TECH. LANG. 

Leslie J. Klein 
Digital Equipment Corp. 

ZK02-3/N30 
110 Spit Brook Road 
Nashua, NH 03062 
DIGITAL COUNTERPART 
Celeste La Rock 
Digital Equipment Corp. 

ZK02-3/Q08 

110 Spit Brook Road 

Nashua, NH 03062 
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LARGE SYSTEMS 

CHAIR 

E.F. Berkley Shands 
Washington University 
Department of Computer Science 
P.0. Box 1045 
St. Louis. MO 63186 
(314) 889-6636 

UUCP: BERKLEYS WUCS. UUCP 
BITNET: Berkleys Uunet 
COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Clyde T. Poole 

The University of Texas at Austin 
Department of Computer Sciences 
Taylor Hall 2.124 
Austin, TX 78712-1188 
(512) 471-9551 

A RPAN ET/CSNET: ctp(« sally.utexax. edu 
36 BIT SYSTEMS 

Clive Dawson 

Microelectronics & Computer Technology Corp. 

9430 Research Blvd. 

Echelon Bldg. #1. Suite 200 
Austin. TX 78759 
(512) 343-0860 

A RPAN ET/CSNET: CLIVE (a MCC. COM 

SYMPOSIUM REPRESENTATIVE 

Vacant 

DISTRIBUTED SYSTEMS 

Don Kassebaum 
Computation Center 
University of Texas at Austin 
Austin, TX 78712 
(512) 471-3241 

ARPANET: CC.KASSEBAUMfn'A20.CC.UTEXAS.EDU 
SEMINARS REPRESENTATIVE 
Robert C. McQueen 
(201) 428-4242 

ARPANET: SIT.MCQUEENtflCu20B.COLUMBIA.EDU 
SUPERCOMPUTING 
Vacant 

SIG VICE-CHAIRMAN 

Ralph M. Bradshaw 
Johnson & Johnson 
Research & Scientific Services 
Management Information Center 
Raritan. NJ 08869-1489 
(201) 685-3434 

LIBRARY REPRESENTATIVE 
SIR/MENU BALLOT 

Jack Stevens 
The Gillette Company 
Technical Services, 4U-3 
1 Gillette Park 
Boston, MA 02106-2131 
(617) 463-2089 
SIG MARKETING 
Steve Attaya 
Weiner Enterprises 
P.O. Box 23607 
Harahan, LA 70183 
(504) 733-7055 

ARPANET:G.ATTA YAtnR20.UTEXAS.EDU 
CORPORATE ISSUES 
Ralph Bradshaw 
Johnson & Johnson 
Research and Scientific Services 
Management Information Center 
Raritan, NJ 08869-1489 
(201) 685-3434 
DEC COUNTERPARTS 
Dave Braithwaite 
Digital Equipment Corporation 
Marlboro, MA 
Rich Whitman 

Digital Equipment Corporation 
Marlboro, MA 
Reed Powell 

Digital Equipment Corporation 
Marlboro, MA 



MUMPS SIG 

CHAIRMAN 

Chris Richardson 
Richardson Computer Research 
P.O. Box 8744 
La Jolla, CA 92038 
(619) 488-6193 
NEWSLETTER EDITOR 
VICE-CHAIR 
COMMCOMM REP. 

Mark J. Hyde 

Advanced Computing Services 

209 Ardsley Drive 

DeWitt, NY 13214 

BITNET: MJHYDEt® SUNRISE 

INTERNET: MJHYDE(ff>SUNRISE.ACS.SYR.EDU 

(315) 446-7223 

SYMPOSIUM SCHEDULER 

Brad Hanson 
Group Health, Inc. 

2829 University Ave., S.E. 

Minneapolis, MN 55414 
(612) 623-8427 

LIBRARY REPRESENTATIVE 
PD P-11 WORKING GROUP REP. 

Michael McIntyre 
PRx, Inc. 

43 Bradford Street 
Concord, MA 01742 
(617) 369-3566 

SEMINARS REPRESENTATIVE 

Edward Woodward 
Science Applications Inti. Corp. 

10260 Campus Point Drive MS42 
San Diego, CA 92121 
(619) 535-7210 

CAMPGROUND COORDINATOR 
ASSIST. SYMPOSIUM SCHEDULER 

Jerry Hsu 
Rubicon Corp. 

1200 E. Campbell 
Richardson, TX 75083 
(214) 231-6591 

SESSION NOTES EDITOR 

Bob Van Keuren 
4087 Chamoune Avenue 
San Diego, CA 92105 
(619) 283-5285 

PAST CHAIR 

MUMPS DEV. COMMITTEE REP. 

Mark Berryman 
Digital Equipment Corp. 

3 Results Way (MR03-2/H7) 

Marlborough, MA 01752 
(617) 467-4875 

BITNET: BERRYMAN(ff>DSM.DEC.COM 
DEC COUNTERPART 
Dave Smith 

Digital Equipment Corp. 

2 Iron Way (MR03-2/H7) 

Marlborough, MA 01752 
(617) 467-2397 

ALTERNATE DEC COUNTERPART 

Denise Simon 
Digital Equipment Corp. 

129 Parker Street (PK02-1/M23) 

Maynard, MA 01754 
(617) 493-9077 


NETWORKS SIG 

CHAIRMAN 

Stuart Lewis 
Douglas Fum. Corp. 

(312) 458-1505 

COMMUNICATIONS COMMITTEE REP. 
Bob Gustafson 
Northeast Utilities 
(203) 665-5082 
NEWSLETTER EDITOR 
Judi Mandl 

UCONN Health Center 
263 Farmington Ave. Bldg. 19 
Farmington, CT 06032 
SEMINAR UNIT REP & 

VICE (BACKUP) SIG CHAIR 
Sandy Traylor 
Target Systems, Inc. 

(714) 921-0112 

SYMPOSIA COORDINATOR 
Bill Hancock 
(817) 261-2283 

STANDARDS COORDINATOR 
Jim Ebright 
Software Results Corp. 

(614) 267-2203 

ASSISTANT NEWSLETTER EDITOR 
Judi Mandl 
UConn Health Center 
(203) 674-3912 

SESSION NOTES EDITOR 
Mary Marvel-Nelson 
General Motors Research Lab. 

(313) 986-1382 
DEC COUNTERPART 
Monica Bradlee 
(617) 486-7341 



OFFICE AUTOMATION SIG 

CHAIR 

Katherine “Kit” Trimm 
Pivotal, Inc 
Tucson, AZ 
(602) 886-5563 
VICE CHAIRMAN 

Ralph Bradshaw 
Johnson and Johnson 
Raritan, NJ 
(201) 685-3434 

COMMUNICATIONS REPRESENTATIVE 
Mary Jane Bolling 
Foreign Mission Board 
3806 Monument Avenue 
Richmond, VA 23230 
(804) 353-0151 

SYMPOSIA COORDINATOR 

Mitch Brown 
GenRad, Ind. 

Waltham, MA 
(617) 369-4400 x3052 
NEW MEMBER COORDINATOR 
Tricia Cross 

American Mathematical Society 
P.O. Box 6248 
Providence, RI 02940 
(401) 272-9500 
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BOF COORDINATOR 
Ray Kaplan 
PIVOTAL, Inc. 

Tucson, AZ 
(602) 886-6563 
NEWSLETTER EDITOR 
Therese LeBlanc 
T.M. LeBlanc & Assoc. 

Wheeling, IL 
(312) 459-1784 
LIBRARY 

Bob Hassinger 

Liberty Mutual Research Center 
Hopkington, MA 
(617) 435-9061 

OA TAPE COORDINATOR 
Mary Jane Boiling 
Foreign Mission Board 
3806 Monument Avenue 
Richmond, VA 23230 
(804) 353-0151 
SYMPOSIA ASSISTANT 
Sal Gianni 
Northeast Utilities 
Hartford, CT 
(203) 665-5652 
STORE COORDINATOR 
Mike Jackson 
Air Force Operational 
Test and Evaluation Center 
Kirtland AFB, NM 
(505) 846-5641 

PERSONAL COMPUTER SIG LIAISON 

Cheryl Johnson 
Grinnell College 
Grinnell, IA 
(515) 236-2570 

OA LUG COORDINATOR 
Tom Orlowski 

American Council on Education 
1 DuPont Circle (Suite 110) 
Washington, DC 
(202)939-9371 

OA SIG COORDINATOR 
Joe Whatley 
Neilson Media Research 
375 Patricia Avenue 
Dunedin, FL 33528 
(813)734-5473 

SESSION NOTE EDITOR 

George Bone 
194 Nalisty Drive 
Vallejo, CA 94590 
(707) 646-2531 



PERSONAL COMPUTER SIG 

CHAIR 

Lynn Jarrett 

San Diego Union-Tribune Pub. Co. 

350 Camino de la Reina 
San Diego, CA 92108 
(619) 293-1130 

WORKSTATIONS/MACS/PRO 
WORKING GROUP CHAIRMAN 

Thomas R. Hintz 
Univ. of Florida 
IFAS Computer Network, 

Bldg, 120 

Gainesville, FL 32611 
(904) 392-5180 

VICE, CHAIR RAINBOW W/G CHAIRMAN 
Lynn Jarrett 

Union Tribune Publishing Co. 

P.O. Box 191 
San Diego, CA 92108 
(619) 299-3131 xll30 


VAXMATE WORKING GROUP CHAIRMAN 

Frederick G. Howard 
Eastman Kodak Company 
901 Elmgrove Road, D345-LP 
Rochester, NY 14650 
(716) 253-2363 

VOLUNTEER COORDINATOR 

Pierre M. Hahn 
SUNY HSC-T10-028-8101 
Stony Brook, NY 11794 
LIBRARIAN Rep. 

Ron S. Hafner 
Hafner and Associates 
P.O. Box 2924 
2499 Wellingham Dr. 

Livermore, CA 94550 
(415) 422-2149 

COMMUNICATIONS REPRESENTATIVE 

Kenneth LeFebvre 
Sytek, Inc. 

19 Church St 
P.O. Box 128 
Berea, OH 44017 
(216) 243-1613 
NEWSLETTER EDITOR 
Gary Rice 
McDonnell Douglas 
5555 Garden Grove Blvd. 

MS: K200 77/200 
Westminster, CA 92683 
(714) 952-6582 

RAINBOW/DECmate W.G. CHAIR 

Vince Perriello 

Crosfield Composition Systems 
One Crosfield Ave. 

West Nyack, NY 10994 
(914) 353-4000 

SYMPOSIA COORDINATOR 

Jimbo Wilson 

Natl Tech. Inst for Deaf 

Rochester Inst of Tech. 

P.O. Box 9887 
Rochester. NY 14623 
(716) 475-6241 

SESSION NOTES EDITOR 

Dr. Tom. Warren 
Oklahoma State Univ. 

Dept of English 
Dir. Tech. Writing Program 
Stillwater, OK 74078 
(405) 624-6138 

PCS A WORKING GROUP CHAIRMAN 

To be announced 
MEMBERS-AT-LARGE 
Michael Bowers 
Univ. of California 
Animal Science Department 
Davis, CA 95616 
(916) 752-6136 
Theodore Needleman 
Odea Tech. 

67 W. Burda PI. 

Spring Valley, NY 10977 
(914) 250-100 

DEC COUNTERPARTS 

PERSONAL COMPUTING SYSTEMS GROUP 
Anita Uhler 

Digital Equipment Corporation 

LJ02/13 

30 Porter Road 

Littleton, MA 01460 

(617) 486-2397 

PRO 

Jeff Slayback 
Digital Equipment Corp. 

ML021-2/U12 
146 Main Street 
Maynard, MA 01754 
(617) 493-9340 

BUTTON COORDINATOR 

Ken Strieker 

Martin Marietta Aerospace 
P.O. Box 5837 MP 320 
Orlando, FL 32855 
(305) 356-6589 


CAMPGROUND COORDINATOR 

Jim Hobbs 
Adolf Coors Co. 

Golden. CO 80401-1295 
(303) 277-2855 

SEMINARS COORDINATOR 
Tim Bundrick 
3480 TCHTW/TTVC 
Goodfellow AFB.TX 76908-5000 
(915) 657-5424 



RSTS SIG 

CHAIRMAN 

Charles Mustain 
Stark County School system 
Data Services Division 
7800 Columbus Rd. N.E. 

Louisville, OH 44641 
(216) 875-1431 

COMMUNICATIONS REPRESENTATIVE 
STORE REPRESENTATIVE 

Ed Beadel 

Instructional Computer Center 
S.U.N.Y. College at Oswego 
Oswego, N.Y. 13126 
(315) 341-3055 

SYMPOSIA COORDINATOR 
Glenn Dollar 

Digital Computer Consultants Inc. 

21363 Lassen St, Suite 205 
Chatsworth, CA 91311 
(818) 341-9171 

ASS’T SYMPOSIA COORDINATOR 
Dan Stoller 

Natural Country Farms 
P.O. Box 758 
58 West Road 
Rockville, CT 06066 
(203) 872-8346 
NEWSLETTER EDITOR 

Terence M. Kennedy 
St. Peter’s College 
Department of Computer Science 
2641 Kennedy Blvd. 

Jersey City, NJ 07306 
(201) 435-1890 

LIBRARY REPRESENTATIVE 

R.R. Patel (PAT) 

Krupp/TaylorUSA 
12800 Culver Blvd 
Los Angeles, CA 90066 

(213) 306-3646 

PRE-SYMPOSIA SEMINAR COORDINATOR 

Scott Castleberry 
1750 North Collins 
Suite 108 

Richardson, TX 75080 

(214) 437-3477 
VICE CHAIRMAN 

WISH LISTS COORDINATOR 
Lynnell Koehler 
Campus America 
POISE Prod. Ctr. 

201 North Nevada Avenue 
Roswell, NM 88201 
(505)625-5500 
EDUSIG LIAISON 

George Wyncott 

Purdue University Computer Center 
W. Lafayette, IN 
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RSTS PRODUCT PLANNING COORDINATOR 

Errol E. Ethier 

Information Design and Management, Inc. 
23 Hunting Avenue 
(617) 842-4220 
Shrewsbury, MA 01545 
DEC COUNTERPART 
Kathy Waldron 

Digital Equipment Corporation 
Continental Blvd. 

Merrimack, NH 03054 
MEMBERS-AT-LARGE 

Edward F. Beadel, Jr. 

Manager 

Instructional Computing Center 

S.U.N.Y. College at Oswego 

Oswego, NY 13126 

(315) 341-3055 

Mark Hartman 

Jadtec Computer Group 

546 W. Katella Avenue 

Orange, CA 92667 

(714) 997-8928 

Jeff J. Killeen 

Information Design & Management, Inc. 

31 Hopedale Street 
Hopedale, MA 01747 


USX 
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RSX SIG 

CHAIRMAN 

Dan Eisner 
Perkin-Elmer Corp. 

Garden Grove, CA 
SYMPOSIA COORDINATOR 
Rick Sharpe 
Toledo Edison 
Toledo, OH 

PRE-SYMPOSIUM SEMINAR COORDINATOR 

Hans Jung 
Associated Press 
New York, NY 

COMMUNICATIONS REPRESENTATIVE 

Jay Allen Bennett 
Logisticon, Inc. 

5035 Whitneyville Road 
Ada, MI 49301 
(616) 452-1823 
NEWSLETTER EDITOR 

MULTI PROCESSORS WORKING GROUP COORDINATOR 

Bruce Mitchell 

Machine Intelligence & Industry Magin 
Byron, MIN 

STORE COORDINATOR 

Jim Hopp 

Carlton Financial Computation 
South Bend, IN 
SESSION NOTE EDITOR 
Burt Janz 
BHJ Associates 
Nashua, NH 
LIBRARIAN 

Glenn Everhart 
Mt. Holly, NJ 

CAMPGROUND COORDINATOR 

Jerry Ethington 
Prolifix Inc. 

Frankfort, KY 
DEC COUNTERPARTS 
Lin Olsen 
Nashua, NH 
Dick Day 
Nashua, NH 

WORKING GROUP COORDINATOR 

Sharon Johnson 
Epidemiology 
Minneapolis, MN 


WORKING GROUP CHAIR 

Evan Kudlajev 
Philadelphia Electric Co. 

Philadelphia, PA 

RSX GROUP CHAIR SOFTWARE CLINIC COORD. 

Roy S. Maull 
U.S. Air Force 
Offutt AFB, NE 

SOFTWARE CLINIC COORDINATOR 

Bruce Zielinski 
RCS 

Moorestown, NJ 

VOLUNTEER COORDINATOR 

Gary Maxwell 

U.S. Geological Survey 

Menlo Park, CA 

SRD WORKING GROUP COORDINATOR 

Bob Turkelson 

Goddard Space Flight Center 
Greenbelt, MD 

ACCOUNTING & PERFORMANCE WORKING GROUP COORD. 

Denny Walthers 
American McGaw 
Irvine, CA 

MENU COORDINATOR 

Ed Cetron 

Center for Biomedical Design 
Salt Lake City, UT 
MEMBERS-AT-LARGE 
Jim McGlinchey 
Warren ton, PA 
Jim Neeland 
Hughes Research Labs. 

Malibu, CA 

Anthony E. Scandora, Jr. 

Argonne National Laboratory 
Argonne, IL 
Ralph Stamerjohn 
Creve Coeur, MO 



RT-11 SIG 

CHAIRMAN 

John T. Rasted 
JTR Associates 
58 Rasted Lane 
Meriden, CT 06450 
(203) 634-1632 

COM. COM VOTING REP. 

COBOL CONTACT 
Bill Leroy 

The Software House, Inc. 

P.O. Box 52661 
Atlanta, GA 30355-0661 
(404) 231-1484 

STANDARDS COORDINATOR 

Robert Roddy 
Naval Ship Research Ctr. 
Bethesda, MD 20084 
(301) 227-1724 
MACRO CONTACT 

Nick Bourgeois 
NAB Software Services Inc. 
P.O. Box 20009 
Albuquerque, NM 87154 
(505) 298-2346 
NEWSLETTER EDITOR 
TECO CONTACT 

PRODUCT PLANNING CONTACT 
John M. Crowell 
Multiware, Inc. 

2121-B Second St Suite 107 
Davis, CA 95616 
(916) 756-3291 


NETWORKING CONTACT 
Jim Crapuchettes 
Omnex Corp. 

2483 Old Middlefield Way 
Mountain View, CA 94043 
(415)966-8400 
WISH LIST CONTACT 
UNIX/ULTRIX CONTACT 
Bradford Lubell 
L.A. Heart Lab, UCLA 
10833 Le Conte Avenue 
Los Angeles, CA 90024-1760 
(213) 206-6119 
TSX & C CONTACT 
Jack Peterson 
Horizon Data Systems 
P.O. Box 29028 
Richmond, VA 23229 
(804) 740-9244 
RUNOFF CONTACT 
John Davis 

Naval Ship Research Center 
Code 2950 

Bethesda, MD 20084 
(301) 227-1592 
LUG CONTACT 

Ned Rhodes 

Software Systems Group 
2001 North Kenilworth St 
Arlington, VA 22205 
(703) 534-2297 

PERSONAL COMPUTERS 

Dennis V. Jensen 
AMES Labs. ISU/USDOE 
310 Metallurgy 
Ames, Iowa 50011 
(515) 294-4823 

SYMPOSIA COORDINATOR 
Milton Campbell 
Talisman Systems 
Drawer CP-255 
Manhattan Beach, CA 90266 
(213) 318-2206 

TAPE COPY GENERATION 
TAPE COPY DISTRIBUTION 
RT DECUS LIBRARY CONTACT 
Tom Shinal 
Syntropic Technology 
P.O. Box 198 
Waterford, VA 22190 
(703) 882-3000 

PRE-SYMPOSIUM SEMINAR 
RT-11 SUITE MANAGER 

Bruce Sidlinger 
Sidlinger Computer Corp. 
4335 N.W. Loop 410, #209 
San Antonio, TX 78229 

(512) DIG-ITAL 
BASIC CONTACT 

Ralston Barnard 
Div 7523 
Sandia Labs 

Alburquerque, NM 87185 
(505) 844-5115 

PRO RT-11 & HARDWARE 

Bill Walker 

Monsanto Research Corp. 
P.O. Box 32, A-152 
Miamisburg, OH 45342 

(513) 865-3557 
FORTRAN CONTACT 

Robert Walraven 
Multiware, Inc. 

2121-B 2nd St Suite 107 
Davis, CA 95616 
(916) 756-3291 
OTHER LANGUAGES 
Gary Sallee 
19912 Femglen Drive 
Yorba Linda, CA 92686 
(714) 970-2864 
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SITE SIG 

CHAIRMAN 

Timothy Fraser 

Specialized Bicycle Components 
15130 Concord Circle #77 
Morgan Hill, CA 95037 
(408) 779-6229 

SYMPOSIA COORDINATOR 

Sue Abercrombie 
48 Malilly Rd. 

Portland, ME 04103 
(207) 772-2837 

SESSION NOTE EDITOR 
LARGE SYSTEMS SIG LIAISON 

Gary Bremer 
Emerson Electric Co. 

8100 W. Florisant 
St. Louis, MO. 63136 
(314) 553-4448 
NEWSLETTER EDITOR 
NETWORKS SIG LIAISON 
OA SIG LIAISON 

Gregory N. Brooks 
Washington University 
Behavior Research Labs 
1420 Grattan St. 

St Louis, MO. 63104 
(314) 241-7600 ext. 257 
HARDWARE COORDINATOR 
HMS SIG Liason 
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Ask the WOMBAT WIZARD 
Submission Form 


To submit a problem to the WIZARD, please fill out the form below 
and send it to: 


WW Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


Name:_ DECUS Membership No. 

Affiliation:_ 

Address: 


Telephone Number:_ 

Statement of Problem: 


Please following the following guidelines when submitting support 
material: 

1. If you are trying to demonstrate a method or a concept, 
please simplify the procedures, records, and other information 
to the shortest form possible. 

2. Annotate your attachments. Simple comments or hand-written 
notes ("Everything worked until I added this statement.") go a 
long way toward identifying the problem. 

3. Keep an exact copy of what you send. And number the pages 
on both copies. But send everything that is related to your 
question, even remotely. 

4. If you would like a direct response or would like your 
•materials returned, please don't forget to include a stamped, 
self-addressed envelope large enough to hold the materials you 
send. 


3 

O' 
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DATATRIEVE/4GL SIG 

Product Improvement Request Submission Form 


Submittor: 
Address: 


DECUS Membership Number: 
Fi rm: 


Phone: 


Product or Products: 


How to write a PIR 

A PIR should be directed at a specific product or group of 
products. Be sure to give the full name of the product(s) and 
version numbers if applicable. Describe the functionality you 
would like to see in as complete terms as possible. Don't assume 
that the PIR editors or software developers know how it is done 
in some other software product - state specifically how you want 
the software to function. Provide justification of your request 
and give an example of its use. If you can, suggest a possible 
implementation of your request. 


Abstract: (Please limit to one or two short sentences.) 


Description and Examples: (Use additional pages as necessary.) 


[Put my name and address on reverse side, thus:] 


PIR Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 
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SUBMITTING ARTICLES TO HARD NEWS 


The purpose of HARD NEWS, the HMS SIG newsletter, is to 
serve as a forum to share information related to DEC 
hardware with the members of the SIG. As such, the 
existence of the newsletter is entirely dependent on your 
contributions. If you have an HHK item, a better or safer 
way to do something, product news, a tutorial article of 
general interest, etc., we would like to publish it in the 
newsletter. We hope that HARD NEWS will be published at 
least six times a year. 

You can submit material to the editor, Carmen Wiseman, or to 
the HMS SIG chair, Bill Walker. We can accept submissions 
in a wide variety of formats: 

o Items can be sent to the editor on VMS-format RX50s, 
TK50 cartridges, or IBM PC format 5 1/4" floppies. The 
SIG chair prefers RT-11 floppies but can handle any 
reasonable media. 

o Hard copy, like cash, is always acceptable. 
Camera-ready copy will save us a lot of typing, but we 
don't insist on it. You can also use the Hardware 
Submission Form in the "Questionnaires" section of the 
combined SIGs Newsletters. 

o Those of you with access to DCS can send things to 
WALKER or WISEMAN. DCS is usually checked on a daily 
basis. 

o You can reach the SIG chair on CompuServe as 
"Bill Walker 71066,24" or via EasyLink mailbox 62752448 
or MCI Mail account 333-1675. You can reach the editor 
via EasyLink mailbox 62960090 (be sure to say ATTN: or 
TO: Carmen Wiseman somewhere in the body of the 

message) . 

If you have anything to submit, send it! If it is a mess, 
But we can read it, we will get it into the newsletter 
somehow. Finally, if you have any questions about 
submitting material, call one of us. The telephone numbers 
are listed below. 

Contributions can be sent to: 

William K. Walker Carmen D. Wiseman 

Monsanto Research Corp. OR Digital Review 

P.O. Box 32 A-152 == Prudential Tower, Suite 1390 

Miamisburg, OH 45342 800 Boylston Street 

(513) 865-3557 (work) Boston, MA 02199 

(513) 426-7094/0344 (home) (617) 375-4361 (work) 
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HARDWARE SUBMISSION FORM — A SIG INFORMATION INTERCHANGE 
Message 


Contact 

Name 

Address 


Telephone 


Type of equipment 


SUBMIT ANY TYPE OF HARDWARE PROBLEMS AND/OR FIXES. 


SEND TO: 

William K. Walker 
Monsanto Research Corp. OR 
P.O. Box 32 A-152 

Miamisburg, OH 45342 


Carmen D. Wiseman 
Digital Review 

Prudential Tower, Suite 1390 
800 Boylston Street 
Boston, MA 02199 
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Languages <£r Tools SIG — Masters Directory 
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MASTERS APPLICATION 

Name:_Title_ 

Company:_ 

Address:_ 


Network Address: 


Phone: ( ) - 

_Date: 


The Languages & Tools SIG has established the designation “LANGUAGES AND TOOLS MASTER”, to be applied 
to selected, qualified people willing to share their expertise in various subjects with others. Masters are people who are 
knowledgeable enough in one or more languages or tools to be comfortable answering questions about them. The 
qualifications of an L&T Master are: expertise in a specific area, a willingness to have his/her name published as a Master, 
and a willingness to volunteer services in different ways. Each product may have several Masters, and there is an overall 
Masters Coordinator who is a member of the L&T Steering Committee. 

Masters are asked to serve other users (and, under some circumstances, DEC), as a resource on products within their 
competence. In addition to being listed in the L&T Masters Directory (published in the newsletter) as available for 
occasional telephone consultation, Masters may act as ‘Doctors’ at Symposium Clinics, present Symposium sessions on the 
products of interest to them, field test products, interact with DEC product managers when appropriate, or act as a 
reference for a product for Digital salespeople. Especially on mature products, the SIG is anxious for knowledgeable users 
to offer product tutorial sessions at Symposia, and Masters can be of great help here. At Symposia, Masters will wear an 
identifying button bearing the legend “Ask Me About.” and the name of the language or tool in which he/she specializes. 

If you’d like to serve as an L&T Master, please mark the products on which you are willing to answer questions with 
an (for Master). Please mark any other products running at your site with an U A” (for “also running”) to provide 

users with a broader picture of your facilities. (Although not an L&T product, Mumps is included here at the request of 
the Mumps SIG as a service to Mumps users). You may request removal of your name from the Masters Directory at any 
time, although you may continue to be listed for a month or two, because of publication lead times. 

I am qualified to act as an L&T Master for the following products: | | Mumps 



Debug 


Bliss 


CMS 


TPU 


C 



Pascal 


Basic 


MMS 

• 

EVE 

i 

Ada 1 



Fortran 


Cobol 


LSE 


EDT 


APL 



Document 


Dibol 


SCA 


TECO 


RPG 



VAX Notes 


Emacs 


PCA 

Ej 

PL/I 


Scan 



Test Manager 
Runoff & DSR 

TfeX & m E x 

Cobol Generator 
Software Project Mgr 


Briefly describe your experience with those you checked. 


How long have you held your present position?_ 

Are you able to attend at least one symposium each year?_ 

Users are encouraged to seek assistance with products by calling appropriate Masters listed in the Directory. As a 
Master, your name and telephone number will be published in the Masters Directory, and users will call on you for limited 
help from time to time. Please check, below, any additional activities you might do: 

| | Field-test new versions of your product at your work site. 

| | Provide feedback on the product when needed by its DEC product manager. 

EH Act as a reference for the product at the request of Digital Sales or Marketing people. 

Mail to: Dena Shelton, L&T SIG Masters Coordinator, Cullinet Software, Inc., 2860 Zanker Road, 
Suite 206, San Jose, CA 95134. 


*Ada is a trademark of the DoD 
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Languages &; Tools SIG 
WISHLIST QUESTIONNAIRE 

Name:_Title_ 

Company:- 

Address:_ 


__Phone: ( ) __ 

Network Address:_Date:- 

The Languages & Tools SIG is principally concerned with the DEC and public domain software products listed 
below. If your request directly involves one of these products, please check which one (if you have more than one 
request, please use a separate form for each): 



Debug 


Bliss 


CMS 


TPU 

□ 

C 



Pascal 


Basic 


MMS 


EVE 

”1 

Ada 1 



Fortran 


Cobol 


LSE 


EDT 

□ 

APL 



Document 


Dibol 


SCA 


TECO 


RPG 



VAX Notes 


Emacs 


PCA 


PL/I 


Scan 



Test Manager 
Runoff & DSR 
TfeX & IAT e X 
Cobol Generator 
Software Project Mgr 


If your request or suggestion doesn’t relate to one of the products listed above, check which one of the following 
Language & Tools SIG topics it concerns: 


__ 

Newsletter 


Symposium Sessions 

□ 

Pre-Symposium Seminars 


Masters Program 


Working Group Activities 

i 

Session Notes 

— 

Information Folder 

Other L&T SIG topic: 

— 

SIG Tape 


DECUS Store Item 


Wish List Request—brief description: 


Complete description—please explain your request thoroughly; don’t assume we know details of other products or 
services; give examples._ 


Mail to: Shava Nerad, L&T Wishlist Coordinator, MIT, 77 Mass Ave. W91-219A, Cambridge, MA 
02139; (617)253-7438 


1 Ada ie a trademark of the DoD 
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DATAGRAMS are short messages, comments, requests, or answers 
that are published in NETwords. Please fill in the sections below 
and send the DATAGRAM to: 

JUDI MANDL 

UCONN HEALTH CENTER 

263 FARMINGTON AVENUE, BLDG. #19 

FARMINGTON, CT 06032 


Title:_ 

Message: 


Your Name: _ 

Address: _ 

Telephone: _ 

If this is a reply to a previous DATAGRAM, what *7 _ 

Signature:_Date:_ 
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Place I 
Stamp I 
Here ! 


JUDI MANDL 

UCONN HEALTH CENTER 

263 FARMINGTON AVENUE, BLDG. #19 

FARMINGTON, CT 06032 


Fold Here 
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OFFICE AUTOMATION SIG 
SYSTEM IMPROVEMENT REQUEST BALLOT 


DECUS Membership Number 


INSTRUCTIONS: System Improvement Request (SIR) Ballots allow you, the user, to 

assist in the prioritization of the submitted SIR’S before they are forwarded to 

Digital. The total number of points which you may allocate on this ballot may not 
exceed 100 points (absolute value). No more than 10 points may be given to any single 
SIR. Your ballot must be received by MARCH 28 to be counted. 


SIR NUMBER POINTS 


TOTAL 


100 POINTS 
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E. Catherine Ditamore 
ARA Services 
Corp MIS 
The ARA Tower 
1101 Market Street 
Philadelphia, Pa. 19107 
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Name (optional) 
Address (optional) 


RT-11 WISH LIST SURVEY 


DECUS Number (optional) 


1.1 

3.1 

3.7u _ 

3.13a 

5.1b 

1.2 

3.2a 

3.7v 

3.13b 

5.2a 

1.3 

3.2b 

3.7w 

3.13c 

5.2b 

1.4 

3.2c 

3 .lx 

3.13d 

6.1 

1.5 

3.2d 

3.7y 

3.14 

6.2a 

1.6 

_ 3.2e _ 

[_ 3.7z _ 

3.15 

6.2b 

1.7a 

3.3a 

3.7aa 

3.16 

6.2c 

1.7b 

3.3b 

” 3.7bb _ 

3.17a 

6.2d 

1.8 

3.3c 

3.7cc 

3.17b 

6.3 

1.9a 

3.3d 

3.7dd _ 

3.17c 

6.4a 

1.9b 

3.4a 

3.7ee 

3.17d 

6.4b 

1.9c 

J 3.4b _ 

3.8a 

3.17e 

6.4c 

1.9d 

3.4c 

3.8b _ 

3.17f 

6.4d 

1.10 

3.5a 

3.8c 

3.18 

6.5 

1.11 

” 3.5b _ 

3.9a 

3.19a 

6.6a 

1.12 

3.6a 

3.9b 

3.19b 

6.6b 

1.13 

3.6b _ 

3.9c 

3.19c 

6.6c 

1.14 

3.6c 

3.9d 

4.1 

6.6d 

2.1 

3.6d _ 

3.9e 

4.2a 

6.7 

2.2 

3.6e 

3.9f _ 

4.2b 

6.8a 

2.3 

3.6f 

3.9g 

4.3 

6.8b 

2.4 

3.6g 

3.9h 

4.4a 

6.8c 

2.5 

3.7a 

3.9i 

4.4b 

I 6.8d 

2.6 

3.7b 

3.9 j 

4.5a 

6.8e 

2.7 

3.7c 

3.9k 

4.5b 

7 . 

2.8 

3.7d 

3.10a 

4.6 

8. 

2.9 

3.7e 

3.10b 

4.7a 

9.1 

2.10 

3.7f 

3.10c 

4.7b 

9.2a 

2.11 

3.7g 

3. lOd 

4.7c 

9.2b 

2.12 

3.7h 

3. lOe 

4.7d 

9.3a 

2.13 

3.7i 

3. lOf 

4.7e 

9.3b 

2.14 

3.7 j 

3. lOg 

4.7f 

10.1 

2.15 

3.7k 

3. lOh 

4.7g 

10.2 

2.16 

3.71 _ 

3. lOi 

4.7h 

10.3 

2.17 

3.7m 

3.10 j 

4.7i 


2.18 

3.7n 

3.10k 

4 • 7 j 


2.19 

3.7o 

3.101 

4.7k 


2.20 

3.7p 

3.10m 

4.71 


2.21 

_ 3.7q _ 

3. lOn 

4.7m 


2.22 

3 .It 

3.11a 

4.7n 


2.23 

3.7s 

3.11b 

4.7o 


2.24 

3.7t _ 

3.12 

5.1a 



Send Responses to: RT-11 Wish List Survey 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 
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NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 




NOTES 
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“The Following are Trademarks of Digital Equipment Corporation” 
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DATATRIEVE 

MicroVAX 
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DEC 

PDP-11 

VAX 

DECmux 

P/OS 

VAXcluster 

DECnet 

Rainbow 

VAXMATE 

DECnet/E 

ReGIS 

VAXstation 

DECwindows 

RSTS 

VAX/VMS 

FMS 

RSX 

VMS 

GIDIS 

RSX-11M 

VT50 (et.al) 

IAS (et.al) 

LN03 

RT-11 

WPS-PLUS 


Copyright @ DECUS and Digital Equipment Corporation 1988 
All Rights Reserved 

The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equip¬ 
ment Corporation or DECUS. Digital Equipment Corporation and DECUS assume no responsibility for any errors that may appear 
in this document. 

It is assumed that all articles submitted to the editor of this newsletter are with the authors’ permission to publish in any DECUS 
publication. The articles are the responsibility of the authors and, therefore, DECUS Digital Equipment Corporation, and the editor 
assume no responsibility of liability for articles or information appearing in the document. The views herein expressed are those of 
the authors and do not necessarily express the views of DECUS or Digital Equipment Corporation. 

ACMS is a trademark of McDonnell Douglas H.I.S. Division; ADA is a registered trademark of U.S. Government; CP/M is a 
registered trademark of Digital Research, Inc.; HP is a registered trademark of Hewlett-Packard Company; UNIX is a registered 
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trademark licensed to Apple Computer, Inc.; RMS is a trademark of American Management Systems, Inc.; IBM is a registered 
trademark of International Business Machines Corporation; AT&T is a trademark of American Telephone & Telegraph Com¬ 
pany. 
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STATUS CHANGE 

Please notify us immediately to guarantee 
continuing receipt of DECUS literature. Allow 
up to six weeks for change to take effect. 

( ) Change of Address 

( ) Please Delete My Membership Record 

(I Do Not Wish To Remain A Member) 

DECUS Membership No:_ 

Name:_ 

Company:_ 

Address:_ 


State/Country:_ 

Zip/Postal Code: _ 


Mail to: DECUS - Attn: Subscription Service 
219 Boston Post Road, BP02 
Marlboro, Massachusetts 01752-1850 

USA 
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